Re: [PATCH v3] travis-ci: Disable C++ optional objects on AArch64 container

[Daniel P . Berrangé]

On Tue, Feb 09, 2021 at 03:12:30PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/9/21 2:41 PM, Peter Maydell wrote:
> > On Tue, 9 Feb 2021 at 13:32, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >> Migration of this job is pending of Cleber's possibility to add an AArch64
> >> runner to Gitlab-CI, right? Then we need someone to support and maintain
> >> the hardware... I don't think anybody volunteered.
> > 
> > We have the hardware already. Effectively Alex is maintaining it...
> 
> I missed to read if Alex volunteered for this task but am certainly
> happy if he is :) Although this should be documented somewhere (who
> to contact if the AArch64 runner starts to fail?).
> 
> Assuming Cleber's runner script is merged and working on the AArch64
> runner, then we need to figure how contributors can use it.
> Assuming this runner will be registered under the QEMU organization
> namespace in Gitlab, then contributors would have to open a Merge
> Request to trigger the CI jobs (similarly to when you push to the
> /staging branch). Then we would cancel the MR. We can ask contributors
> to cancel their MR once testing done.
> 
> Midway could be having maintainers opening such MR?
> 
> I have no idea, just asking questions to see if other have ideas or
> see the big picture here.

To start with, I'd say these custom runners are exclusively for the
staging branch merge testing done by Peter. If the jobs fail he will
just report them to the maintainer's pull request in the normal way
that's been done historically.


For a second phase, I think we should consider whether we really
still need / want subsystem maintainers to be sending pull requests
via email at all.

Many subsystem maintainers are already using GitLab for doing CI testing
before sending a pull request. Then they send email to the list, which
then has to be applied to a staging branch and pushed back to GitLab.
The loop through email is pretty crazy here.

It would be a lower overhead workflow if the subsystem maintainers just
opened a Merge request directly against the main repo in gitlab. This
will trigger CI, and if it passes, then it merely needs someone to
hit "merge". If it needs rebasing due to conflicts, gitlab can immediately
tell the maintainer which reduces the turn around time.


As for individual contributors using merge requests, that is of course
a technical possibility, but that would be quite a radical change in
QEMU's contribution philosphy, so I think it is wise to ignore that
to avoid getting distracted in the short term.

Focus on getting better use of GitLab and CI for subsystem maintainers
as our primary near term goal, to reduce the burden on the person doing
merges to master.

I made a suggestion for this here but no one replied...

   https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg04897.html

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|