seabios.git branch state

seabios.git branch state

[Jan Beulich]

Ian,

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?

Thanks, Jan

Re: seabios.git branch state

[Ian Campbell]

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.

Ian.

Re: seabios.git branch state

[Jan Beulich]

>>> On 25.06.13 at 12:29, Ian Campbell <Ian.Campbell@citrix.com> 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.

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

Re: seabios.git branch state

[Ian Campbell]

On Tue, 2013-06-25 at 12:47 +0100, Jan Beulich wrote:
> >>> On 25.06.13 at 12:29, Ian Campbell <Ian.Campbell@citrix.com> 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
> 

Re: seabios.git branch state

[Jan Beulich]

>>> On 26.06.13 at 19:02, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2013-06-25 at 12:47 +0100, Jan Beulich wrote:
>> >>> On 25.06.13 at 12:29, Ian Campbell <Ian.Campbell@citrix.com> 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
> ?

That would sound reasonable, but ...

> (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).

... afaic I adjusted my script already, so if it's only me asking, you
can do whatever suits you best (including keeping things as they
are, albeit perhaps you'd want to indeed kill the useless/confusing
master branch.

> 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...

If we do, then I think we should create it as port of the release
process. But as said - I think keeping the current scheme less the
master branch would be fine too (allowing, if it so happens, to
have a branch shared across releases).

Jan

Re: seabios.git branch state

[Ian Campbell]

On Thu, 2013-06-27 at 07:35 +0100, Jan Beulich wrote:
> >>> On 26.06.13 at 19:02, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2013-06-25 at 12:47 +0100, Jan Beulich wrote:
> >> >>> On 25.06.13 at 12:29, Ian Campbell <Ian.Campbell@citrix.com> 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
> > ?
> 
> That would sound reasonable, but ...
> 
> > (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).
> 
> ... afaic I adjusted my script already, so if it's only me asking, you
> can do whatever suits you best (including keeping things as they
> are, albeit perhaps you'd want to indeed kill the useless/confusing
> master branch.

OK, I've just done that.

Thanks,
Ian.