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