Re: Migrating custom qemu.org infrastructure to GitLab

[Daniel P . Berrangé]

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

> 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.

> I suppose tags are hints to maintainers, so keeping something similar to
> the MAINTAINERS file separation could be useful.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|