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

Re: [Xen-devel] Proposed force push of staging to master



>>> On 17.02.14 at 17:49, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> George Dunlap writes ("Re: Proposed force push of staging to master"):
>> On 02/17/2014 12:08 PM, Ian Jackson wrote:
>> > So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
>> > xen.git#master and call it RC4.  Comments welcome.
>> 
>> Thanks for the analysis.  This seems like a good plan.
> 
> I have done this (RC4 is tagged, tarballs are in production).
> 
> I also had to force push the change below to xen.git#master.
> 
> Can I request that we don't change this back to say "master" until we
> are done with 4.4.0 ?  Either way we have to update Config.mk with new
> qemu upstream versions, but if we set this to "master" in between RCs,
> I end up having to do it as a force push in the middle of the RC
> production which is out-of-course, error-prone, and suboptimal.
> 
> It is IMO better to put a commit hash in QEMU_UPSTREAM_REVISION in
> Config.mk (updated when the qemu-upstream tree has passed its push
> gate).
> 
> 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
>   * make change to xen.git#staging to update QEMU_UPSTREAM_REVISION
>     to new commit hash
>   * whatever is in xen.git#master is what gets called rcN
>     (ie we tag xen.git and */qemu-upstream-unstable.git with the rcN
>      tags, but we don't use the actual tag name in Config.mk)

Do you propose this just for the RC phase, or do you propose
reverting the decision to have this set to master altogether? 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.
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).

Jan


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


 


Rackspace

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