Re: Migrating custom qemu.org infrastructure to GitLab

[Thomas Huth]

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

>> 2. wiki.qemu.org is a MediaWiki instance. Account creation is a hurdle
>> to one-time or new contributors. It is unclear whether GitLab's wiki
>> is expressive enough for a lossless conversion of the existing QEMU
>> wiki. Any volunteers interested in evaluating the wiki migration would
>> be appreciated.
> 
> Yeah, this is a potentially big piece of work. We didn't finish this
> in libvirt either. Looking at the libvirt mediawiki though, I decided
> not todo a straight export/import of all content.
> A bunch of content was horribly out of date and needed deleting as
> it was irrelevant to anyone, or outright misleading wrt current state
> of the world.

Having done some clean-up work in the QEMU wiki in the past already, I
can only agree with Daniel. I don't think that we want a 1:1 conversion
of the existing Wiki, we should rather start from scratch and only
convert the important pages. Or should we really keep stuff like
https://wiki.qemu.org/Documentation/KQemu around?

Maybe we should also rather convert the important content into parts of
the main website instead, just like Daniel mentioned it.

Whichever way we choose, I volunteer to help here if my spare time permits.

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

 Thomas