Re: [Xen-devel] seabios.git branch state

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-06-25 at 12:47 +0100, Jan Beulich wrote:
> >>> On 25.06.13 at 12:29, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Fri, 2013-06-21 at 10:00 +0100, Jan Beulich wrote:
> >> for xen-unstable so far I have been tracking the xen-unstable
> >> branch, yet this has been lagging behind 1.7.1-stable-xen for a
> >> couple of weeks. What are the intentions here?
> > 
> > I would recommend that you instead track the
> > Config.mk:SEABIOS_UPSTREAM_TAG variable.
> > 
> > I'm not sure what the best strategy here is, it seems like at some point
> > I have ended up only pushing to the X.Y.Z-xen-stable branches rather
> > than the xen-unstable branch. This probably makes sense since otherwise
> > the xen-unstable branch would either need to be rebasing (for new
> > upstream releases/stable branches) or have a complicated remerging
> > strategy which I don't really want to get into.
> > 
> > Perhaps I should just nuke the xen-unstable branch? I could switch to
> > X.Y.Z-{xen-unstable,xen-A.B} branches but given that our releases
> > reference particular commits/tags via SEABIOS_UPSTREAM_TAG I'm not sure
> > that would be worthwhile.
> 
> I think it would - the way the build process works when done
> entirely from the root of the tree doesn't mean everyone will or
> has to do it this way too.

So how about, where X.Y.Z is the seabios version and A.B is the Xen
version or "master":
X.Y.Z-stable/xen-A.B 
X.Y.Z-stable/xen-master
?
(NB X.Y.Z-stable is the upstream branch name). Does that work for you or
do you also want a (necessarily rebasing) "rebasing/xen-A.B" branch
which points to the current X.Y.Z-stable/xen-A.B? Bear in mind that's
more work for me (only small, but the issue is more that I am likely to
forget because seabios updates are rare).

Do we need to create X.Y.Z-stable/xen-A.B as part of the release process
or is on the first SeaBIOS push to a stable branch sufficient? I'm not
sure how many SeaBIOS patches there will be...

Ian.

> 
> For instance, I very much dislike the pulling down of a fresh git
> clone during building - this wastes time and disk space. Instead
> I maintain separate clones of the individual repos, and when
> taking a snapshot I just combine those of the individual trees.
> Which immediately makes it undesirable (but not impossible) to
> look into specific files of the xen tree to know which tags to use
> for the other ones - I'd expect that simply the tip of the master
> branches of all respective trees can be tied together (i.e.
> irrespective of possibly a push to update one of the tags not
> having happened yet even if the actual tree's changes did pass
> the push gate already).
> 
> But anyway - I'll see to adjust my snapshotting scripts accordingly.
> 
> Jan
> 



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