Re: [PATCH 0/5] QEMU Gating CI

[Philippe Mathieu-Daudé]

On 4/27/20 4:28 PM, Cleber Rosa wrote:
> On Mon, 27 Apr 2020 12:51:36 +0200
> Philippe Mathieu-Daudé <address@hidden> wrote:
>
> > On 4/27/20 7:12 AM, Cleber Rosa wrote:
> > > On Thu, 23 Apr 2020 23:28:21 +0200
> > > Philippe Mathieu-Daudé <address@hidden> wrote:
> > [...]
> > > > In some cases custom runners are acceptable. These runners won't be
> > > > "gating" but can post informative log and status.
> > >
> > > Well, I have the feeling that some people maintaining those runners
> > > will *not* want to have them as "informational" only.  If they
> > > invest a good amount of time on them, I believe they'll want to
> > > reap the benefits such as other not breaking the code they rely on.
> > >   If their system is not gating, they lose that and may find
> > > breakage that CI did not catch.  Again, I don't think "easily
> > > accessible" hardware should be the only criteria for
> > > gating/non-gating status.
> > >
> > > For instance, would you consider, say, a "Raspberry Pi 4 Model
> > > B", running KVM jobs to be a reproducible runner?  Would you blame a
> > > developer that breaks a Gating CI job on such a platform and says
> > > that he can not reproduce it?
> >
> > I'm not sure I understood the problem, as I'd answer "yes" but I
> > guess you expect me to say "no"?
>
> What I mean is: would you blame such a developer for *not* having a
> machine himself/herself that he/she can try to reproduce the failure?
> And would you consider a "Raspberry Pi 4 Model B" an easily available
> hardware?

My view on this is if someone merged code in mainstream QEMU and 
maintains it, and if it is not easy to reproduce the setup (for a bug 
reported by a CI script), then it is the responsibility of the 
maintainer to resolve it. Either by providing particular access to the 
hardware, or be ready to spend a long debugging session over email and 
multiple time zones.

If it is not possible, then this specific code/setup can not claim for 
gating CI, and eventually mainstream isn't the best place for it.

> > [...]