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