Re: Proposal to deploy GitLab on gnome.org

[Bastien Nocera <hadess hadess net>]

Hey,

On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> [Written on behalf of Alberto Ruiz, Carlos Soriano, Andrea Veri,
> Emmanuele Bassi and myself.]
>
> Please bear in mind that this is just a recommendation! We are not
> claiming to have complete knowledge and we would like to hear
> questions and comments. At the same time, we do ask that members of
> the community approach this proposal with an open mind: please read
> the wiki pages and try to resist making assumptions about GitLab
> without familiarising yourself with it.

I've now read through the documentation, and annotated my early
thoughts on the migration.

- Keep bugzilla URLs working, along with history
  This is very important for code history purposes, and has been
mentioned as an explicit goal at:
https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/#Migration_Possibilities

- Keep cgit URLs working
  Again, important for code history purposes. We often link to those in
bug reports and commit messages. This could probably be achieved
through redirections rather than keeping the cgit instance alive

- Keep git URLs working
  While not a problem for developers (you'd change your gitconfig and
update jhbuild, and done, mostly), it has the potential to break a lot
of flatpaks, possibly also upstream packaging. I know something similar
was done in the Fedora package repos when they migrated, so maybe it's
possible?

- Component bug assignment: g-c-c/g-s-d or gnome-documents/gnome-books
  This is probably the most important one for bug handling. Otherwise
managing bugs for g-c-c and g-s-d, the different components of which
require a lot of domain-specific knowledge, would be terribly unwieldy.

- Equivalent to NEEDINFO?
  This status was pretty important in terms of bug triaging, as the
reporter was allowed to remove that flag when they were done providing
the information, removing the burden from the bug triager to monitor
the bug. Is there an equivalent?

- Cross-module issue searching?
  Again, quite useful in terms of bug triaging, allowing to find a
"root cause" bug, possibly assigned to a different component than the
top level application. For example, a crash in Videos could be in about
7 different modules, being able to search the whole instance would be
useful.

- Mail for own replies (a-la bugzilla)
  - This is also a useful tool for bug triaging, as all the comments
end up in my Bugzilla folder, and I can search through them. I'm
guessing/hoping it's possible.

- Handling of private bugs?
  Bugzilla has the ability to create private bugs, for security and
community feedback management purposes. Does GitLab allow that?

- Bugzilla yearly reports
  Is there some statistics tool builtin to GitLab?

- Bugzilla points
  Will they be migrated? :)

Overall, the migration is a good idea, especially the ability to report
bugs and contribute without a GNOME specific account. I hope the
information about how different teams and bugzilla triagers use
Bugzilla, in particular, was of interest.

Cheers