Re: Migrating custom qemu.org infrastructure to GitLab

[Philippe Mathieu-Daudé]

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

We should do some experiments first, because I saw various ways to use
the GitLab ticket tags, and none convinced me it is practical.

Should anyone add any tag? Should we restrict to a set of useful tags?

Current launchpad tags:

    35 arm
    21 linux-user
    17 qemu
    16 ppc
    15 windows
    13 testcase
    11 tcg
    9 mips
    9 usb
    9 qemu-img
    6 i386
    6 feature-request
    2 sh4
    2 patch
    1 s390x
    1 sparc

The patterns I see:

- user-mode vs softmmu
  (linux-user)

- one tag per architecture
  (arm / ppc / mips / i386 / sh4 / s390x / sparc)

- host OS
  (windows)

- accelerator
  (tcg)

- subsystem
  (usb)

- tools
  (qemu-img)

- feature requests

- testcase

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

Note the GitLab roles:
https://docs.gitlab.com/ee/development/permissions.html

    No access (0)
    Guest (10)
    Reporter (20)
    Developer (30)
    Maintainer (40)
    Owner (50)