Re: Proposal to deploy GitLab on gnome.org

[Shaun McCance <shaunm gnome org>]

On Thu, 2017-05-18 at 18:08 +0200, Andre Klapper wrote:
> On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote:
> > That said, here's a potential pain point: in Bugzilla, you can have
> > different components auto-assign to different accounts, and we made
> > these @gnome.bugs fake accounts for teams. The docs team uses this
> > to
> > make it easy to follow docs bugs across products. I don't think
> > GitLab
> > has any sense of components, preferring the more casual labels for
> > categorization.
> When all that overcategorization in a ticket (Bugzilla: 1 "product"
> per
> ticket, 1 "component" per ticket, 0-∞ "keywords" per ticket, random
> freetext in a "whiteboard" entry, upstream's "tags" fields that GNOME
> hides via custom CSS) is turned into a single "Labels" field, with 0-
> ∞
> labels associated to a ticket, and everybody tries to remember adding
> that #user-docs label, and if a GitLab user can receive notifications
> for certain labels (so docs team members could follow activity), I
> don't see a real problem? :)
>
> Our "@gnome.bugs virtual assignee" setup in Bugzilla is a horrible
> hack, due to unavailability of an "allow me to receive notifications
> for these products / components" functionality for ages [1].

I don't disagree with anything you're saying. As long as there's an
easy way to get a list of issues with a specific label across all
projects (and projects in different groups?), then we'll figure it out.
And if there's not, we'll figure it out another way.

This will likely affect other teams that work across projects, like the
translation teams or the newcomers initiative.


> andre
>
> [1] To be fair, a downstream bgo extension got upstreamed at
> https://github.com/bugzilla/extensions-ComponentWatching
> but that's not shipped /by default/ which makes following anything
> that
> is neither a ticket nor a user to stalk rather
> complicated/cumbersome.