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.
