On Tue, 14 Nov 2017 at 20:30:21, Jelle van der Waa wrote: > It's time to switch our to something which is maintained and can be extended > to > our wishes. Flyspray isn't actively maintained, has had several security > issues [1] [2]. > [...]
Great! > # Migration > > There are several options for migrating the bug history to Bugzilla and a few > options are under > debate. (input welcome) > > * No migration at all > * Migrate open bugs > * Migrate open bugs and auto-closing them > * Migrate all bugs > * Migrate all bugs and auto-closing them > > In either case, I believe it would be nice to "archive" the current > bugtracker and make it read > only. Doing no migration and having an archive of the current tickets sounds like a good idea to me -- I can only talk about the aurweb project and the packages projects, though -- maintainers of other components might disagree. After the migration, I would go through the open aurweb tickets on the Flyspray archive, create new tickets for the most important issues (should not be more than 10), fix/implement some of the easy stuff and close the tickets which I think are not worth fixing or implementing. > # User migration > > User migration should be possible as well, except migrating the password, a > mass password reset > would be wise. Since I'm not sure what kind of old hashing method / salt > flyspray uses. Sounds good to me, although I do not see the benefit of doing this if we do not migrate tickets. If users need to reset their passwords, they can as well reregister. There aren't too many things to configure and the profile settings in Flyspray will likely not match what you can configure in Bugzilla anyways. Generally speaking, I am in favor of setting up a fresh Bugzilla instance and not doing any sort of migration. The idea of switching to a new bug tracker came up at least four years ago and my feeling is that all this migration work is what was holding it back for a long time. However, we should make sure that the old Flyspray URLs still work (and redirect to the Flyspray archive). > > # Migration Projects > > Bugzilla has a concept of products with components, so for all our packages > we can create a > component counterpart. It should be possible to auto-assign bugs with the > pkgname <-> maintainer > information from archweb. > > Possible products would be. > > # Products > > * Arch packages (core/extra or split this up) > * Community packages (community) > * Pacman > * AURWeb > * Keyring > * Archweb (new) > * Arch VM / Docker images (new) > * Release engineering Sounds good to me. I would split [core] and [extra]. I would also call the packages projects "[core] packages", "[extra] packages" and "[community] packages"; unless there are technical limitations preventing the use of brackets. These brackets make it much clearer that the names are referring to pacman repositories; and to a novice Arch user, it may not be 100% clear what a "community package" or an "extra package" is. Best regards, Lukas
