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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list