Re: Migrating custom qemu.org infrastructure to GitLab

[Paolo Bonzini]

On 08/07/20 12:53, Daniel P. Berrangé wrote:
> Consider if qemu-web.git is hosted on gitlab, using GitLab CI to
> generate the static site content, and GitLab pages to host the
> website. If a user wants to contribute to qemu-web, they can fork
> the repo and be confident that the CI jobs in their fork are going
> to work in the exact same way as in the master repo. They can use
> GitLab Pages to browse the generated content for their fork to
> see exactly how it will look.
> 
> This eliminates the big pain point in qemu-web contribution. Many
> times I was tripped up with the problem of qemu-web.git requiring
> a version of Jekyll that is incompatible with the version that
> ships on my distro.

I would have no issue with using a pull request workflow for qemu-web.
The lack of "git range-diff" functionality for gitlab is an absolute
showstopper for using it in QEMU, though.

>> GitLab's Continuous Integration (CI) system provides a powerful way to
>> perform actions defined in yaml files in qemu.git. This includes
>> running scripts, builds, publishing build artifacts, etc. We have
>> already begun using it for automated builds and tests:
>> https://gitlab.com/qemu-project/qemu/-/blob/master/.gitlab-ci.yml
> 
> The CI integration has probably been the single best thing about
> libvirt's switch to GitLab.

How do you handle non-x86 platforms?  Has there been any progress in
gitlab runner support for s390 and PPC?

> The Documentation/Platforms content arguably should be part of
> the main qemu.git docs.
> 
> Many of the feature pages are probably better as part of the formal
> QEMU documentation too.

Yes, definitely; but someone has to do the work.  At least the obsolete
features are clearly marked as so.