[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing



On Tue, Jul 24, 2018 at 03:32:09PM +0100, George Dunlap wrote:
> On 07/24/2018 10:34 AM, Jan Beulich wrote:
> >>>> On 24.07.18 at 11:24, <wei.liu2@xxxxxxxxxx> wrote:
> >> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> >>>>>> On 23.07.18 at 18:40, <lars.kurth@xxxxxxxxxx> wrote:
> >>>> # How does this impact me?
> >>>> The contribution workflow is *not* impacted by this change, but once up 
> >>>> and 
> >>
> >>>> running the following will happen once you post a patch or patch series 
> >>>> to 
> >>>> xen-devel:
> >>>> * Patchwork will take patch series from the mailing list and applies it
> >>>> * CI/DC testing is triggered
> >>>> * A test report will be sent as a mail to the patch or the series (aka 
> >>>> the 00 patch of the series)
> >>>>
> >>>> This does mean though that series which do not build or show other 
> >>>> issues, 
> >>>> will likely not be reviewed until the tests pass. This would lessen the 
> >>>> burden on reviewers, as they will know whether the code submitted builds 
> >>>> on a 
> >>>> wide array of environments. 
> >>>
> >>> So how are dependencies between series intended to be dealt with? It
> >>> is not uncommon for someone to say "applies only on top of xyz". The
> >>> implication of "will likely not be reviewed until the tests pass" seems
> >>> unsuitable to me in such a case.
> >>>
> >>
> >> We have been asking everyone to rebase to staging before posting a new
> >> version for a long time.  It is natural for the bot to assume that
> >> everything should apply on top of staging. That would provide most value
> >> to the community.
> >>
> >> For special cases like you just mention, we should aim to provide
> >> mechanisms to manually appoint a branch to be tested.
> > 
> > I'm afraid I disagree again: Tools used should not be dictated. I'm
> > using quilt, not git for my work, and hence I don't maintain any
> > branches anywhere.
> 
> Well it's never been our habit to review patch series sent against
> random private branches.  (x86-next not being a random private branch.)
> The idea would be that you put a tag in the message somewhere that
> indicates what the patchbot should do.  This would probably be just the
> message-id of the patch series, given that (steady state) your previous
> series would have had the bot reply to it with a link.  Something like this:
> 
> Prerequisite-series: <5B506A6E02000078001D5D17@xxxxxxxxxxxxxxxxxxxxxxxx>
> 
> If the sender doesn't add the prerequisite series, then of course it
> won't apply; but the reviewer can choose to ignore the failure in that case.
> 
>  -George

So fwiw, there's a tool called git-series (the author says he's working
on integrating its functionality into the git upstream) that does
exactly this. Most of my recent patches have been sent with it and
you'll actually see what commit from staging my patches are based on and
if I wanted I could record instead the message-id of a posted series it
would depend on. I've spoken with the patchwork folks about support that
tag as well.

--
Doug

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.