Re: Migrating custom qemu.org infrastructure to GitLab

[Philippe Mathieu-Daudé]

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
>