Re: [Xen-devel] Proposed force push of staging to master [and 1 more messages]

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: Proposed force push of staging to master"):
> Do you propose this just for the RC phase, or do you propose
> reverting the decision to have this set to master altogether?

Just for the RC phase.

> In either case, it was only pretty recently that we decided to use
> master here, and I don't think you objected, so I'm a little puzzled
> by the proposal.

We decided to use master here "most of the time".

> I personally think that using master and an explicit tag for RCs is just
> as appropriate as properly naming the RC in
> xen/Makefile:XEN_EXTRAVERSION, and that doing the respective
> adjustments could - if one wanted to - likely be fully automated (albeit
> when I'm doing the same on the stable branches, I didn't bother
> scripting this so far as it's just not happening frequently enough to
> warrant this).

Yes, I agree that it could be automated.  But there's a problem with
doing this on a routine basis.  As you can see from the test report
just sent, a force push requires osstest to construct a new baseline
test.  If that baseline test suffers from some kind of passing problem
(eg, infrastructure problems, or git servers being down at the wrong
moment, or whatever), then osstest wouldn't be able to spot any actual
regressions in the affected tests.

An alternative would be to make these part-of-the-release changes on a
separate git branch, but then people who want to test an RC would have
to do something other than just "git clone xen.git".

It would be possible to have osstest spot the force push and try to
find a tested ancestor of the current master to use as a baseline.
But that would make it impossible to use a forced push to deliberately
introduce a known but tolerable regression.

Stefano Stabellini writes ("Re: Proposed force push of staging to master"):
> On Mon, 17 Feb 2014, Ian Jackson wrote:
> > That is I think the best workflow is:
> >   * make a change to staging/qemu-upstream-unstable.git
> >   * wait for push gate to put it in qemu-upstream-unstable.git
> 
> Does this work because the test infrastructure doesn't obey Config.mk?

Yes.

> In fact, even if the test infrastructure does test the new changes by
> manually setting QEMU_UPSTREAM_REVISION, following your proposed
> workflow we would still miss all the possible bug reports from the
> community between RCs.

I'm suggesting that whenever the qemu-upstream tree is updated, the
hash in Config.mk should be updated too, the way it's done for qemu
trad.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel