On 7/8/20 3:32 PM, Daniel P. Berrangé wrote: > On Wed, Jul 08, 2020 at 03:19:08PM +0200, Philippe Mathieu-Daudé wrote: >> On 7/8/20 1:48 PM, Thomas Huth wrote: >>> On 08/07/2020 12.53, Daniel P. Berrangé wrote: >>>> On Wed, Jul 08, 2020 at 10:52:38AM +0100, Stefan Hajnoczi wrote: >>> [...] >>>>> With this in mind I propose moving qemu.org infrastructure to GitLab >>>>> incrementally. [...] >>> >>> FWIW, I think moving the QEMU infrastructure zoo to GitLab is a very >>> good idea! >>> >>> Daniel already mentioned most of the things that I had in mind after >>> reading your mail (well, actually he mentioned way more things that I >>> had in mind), but let me add some sentences below anyway... >> >> Same comment ;) >> >> I find sometime confusing the see which GitLab features are restricted >> to the paid version and which are available for open source projects. >> >>>>> 5. Issue tracking. Launchpad more or less works, but the login always >>>>> bothers me. If we move git repo hosting then it makes sense to do >>>>> issue tracking on GitLab too. >>>> >>>> The big thing that always bothers me about launchpad is how easy it >>>> is to get confused between issues for QEMU upstream and issues for >>>> legacy releases in Ubuntu distro. >>> >>> +1000 ! >>> >>> I was already thinking of suggesting to move the bug tracker to either >>> gitlab or github or anywhere else during next KVM forum, since it is >>> IMHO a real pain. >>> >>> I've seen so many bugs that users tried to open against the downstream >>> Ubuntu QEMU package but ended up in the upstream tracker instead. Apart >>> from that, the Launchpad UI is partly really horrible in my eyes (for >>> example you never know which action will trigger an immediate change and >>> which needs to be confirmed by pressing a button). Additional many >>> developers don't have a Launchpad account, so bugs can not be assigned >>> properly and you just have to pray that people see the notification >>> e-mails on the mailing list. >>> >>>> There is a question of what todo with existing bugs in launchpad. >>>> >>>> Essentially three choices >>>> >>>> 1. Move all the open bugs to gitlab >>>> 2. Move some relevant bugs to gitlab, but close outdated ones >>>> 3. Leave existing launchpad bugs but don't allow new ones filed >>> >>> I think we could set most (outdated) bugs simply to "incomplete" with a >>> message saying that the reporter should open a new bug on Gitlab if >>> necessary. Then after 60 days, the "incomplete" bugs will expire (i.e. >>> auto-close). >> >> Some users hide their email on launchpad, so we would be hard to simply >> re-import their bug on gitlab. Now if you ask them to import it, it is >> easier. 60 days seem enough to react. >> >> Something that always bugged me on launchpad is you can not Cc other >> people on a bug if they don't have a launchpad account. I haven't >> checked if GitLab allows that (Bugzilla does). > > GitLab doesn't expose anyone's email address. Any interaction with other > users is exclusively via their GitLab user name. So yes, you need an > account to be added to notifications for an issue. > >> We should do some experiments first, because I saw various ways to use >> the GitLab ticket tags, and none convinced me it is practical. > > Why is that ? I find the tagging to be one of the things i really > like coming over from the bugzilla world. It is useful for doing an > initial triage of bugs in particular, to sort them into logical buckets. > > I think that's particularly useful with our subsystem maintainer model, > as it will let us direct bugs towards specific maintainers. > > In libvirt we had some generic labels for all projects > > https://gitlab.com/groups/libvirt/-/labels > > And then further project specific labels > > https://gitlab.com/libvirt/libvirt/-/labels
Excellent, this is exactly what we need, so I'm not worried anymore :) > >> Should anyone add any tag? Should we restrict to a set of useful tags? > > I believe only admins can define the tags, you can't add arbitrary > tags to a project as a user. We are good then (users can still suggest pertinent tags in when opening an issue). > >> I suppose tags are hints to maintainers, so keeping something similar to >> the MAINTAINERS file separation could be useful. > > Regards, > Daniel >
