Re: [Qemu-devel] QEMU Summit 2017: minutes

[Fam Zheng]

On Wed, 11/29 09:31, Cornelia Huck wrote:
> On Tue, 28 Nov 2017 13:30:23 -0500
> John Snow <address@hidden> wrote:
> 
> > On 11/28/2017 04:36 AM, Cornelia Huck wrote:
> > > On Tue, 28 Nov 2017 09:33:52 +0100
> > > Thomas Huth <address@hidden> wrote:
> > >   
> > >> On 27.11.2017 23:03, John Snow wrote:  
> > >>>
> > >>> On 11/23/2017 11:31 AM, Peter Maydell wrote:    
> > >> [...]  
> > >>>> Continuous Integration:
> > >>>>  * Christian Borntraeger: qemu-iotests have broken a lot, they should 
> > >>>> be
> > >>>>    run before patches are merged    
> > >>>
> > >>> This, rather unfortunately, is a huge testing burden. I try to make sure
> > >>> I do it for everything I submit, but for the volume of block patches it
> > >>> really does rely CI. The more we add (to our pitifully sparse iotesting,
> > >>> I might add) the longer it takes. Ensuring per-patch testing begins to
> > >>> take prohibitively long.
> > >>>
> > >>> Perhaps per-pull or per-merge becomes more feasible. Maybe if we do
> > >>> implement a block-next amalgam we'd be able to batch our testing on a
> > >>> weekly basis.    
> > >>
> > >> I think you block-layer folks should do at least run the qemu-iotests
> > >> before sending a pull request to Peter. The iotests should really not be
> > >> broken in upstream master.  
> > > 
> > > This is unlikely to cover the iotest failures on s390 (due to usage of
> > > ccw, strange backing devices, etc.), though. We have basically two
> > > options here:
> > > - Continue to rely on the IBM folks finding those problems (which will
> > >   likely be post-merge, but better than nothing.)
> > > - Have patchew (which has a bot on s390) execute the iotests - which is
> > >   time-consuming.
> > >   
> > 
> > Does patchew test pull requests? Perhaps Peter could wait for an ACK
> > from patchew before committing. Peter and patchew could check PRs in
> > tandem and perhaps he can commit fully only when patchew ACKs.
> > 
> > for PRs specifically, perhaps patchew can indeed send an affirmative ACK
> > to the list indicating success.
> 
> I'd assume patchew can figure out whether it deals with a pull request
> by checking for 'PULL', and we post all patches in a pull request, so
> some special handling might be feasible.
> 
> Fam, what do you think?

Yes, but I guess we need to first address Peter's specific unhappiness about
patchew reports, before placing it in the pull request process: a lot of lines,
especially in the beginning of the email is not quite useful making the email
unfriendly to read.

If we want explicit ACKs from patchew on PULL process, two more changes are
needed (they apply to pull requests only):

1) Fetch from the pull request's git branch instead of applying. This has two
   advantages: when failed to apply a series, patchew doesn't test it, which
   cannot happend if we git-fetch instead of git-am; quite often a pull request
   v2, v3, ... only includes changed patch in the series, making git-am more
   likely to fail, which again is not a problem if we git-fetch.

2) Report if all tests cannot complete in time (e.g. a tester is down and some
   tests cannot run). The rationale is the same as above.

Fam