[OpenAFS] buildbot and packages

[Troy Benjegerdes]

If a pre-stable -> master merge to trunk happens reliably every 3 
months, it might be an obnoxious merge, but it can't be any worse
than merging rxk5 (for gory details, see 
https://bitbucket.org/dahozer/tfs/changeset/10a38e703483fd99b3a41e99cba74f203524f731
)

The artificial version approach you mention also seems like it work
well if we want to keep a more centralized repository approach, and
treat Git like CVS.

But the great thing about Git (and to some extent Gerrit) is the fully
decentralized nature. While we're in the week leading up to a stable branch
point, everyone can just keep working in their own local repositories (or 
even push to Gerrit)

The only thing that stops is approving development changesets to master
on Gerrit for a week while someone does the pre-branch-and-mergeback.

Heck, if I can figure out how to get paid for 4 weeks a year to be the
release-and-merge nazi, it won't require anyone else to do any extra
work... And then you can ask me again after I've done it twice if I 
still think it's a good idea. 

On Mon, Sep 17, 2012 at 03:55:02PM -0700, Russ Allbery wrote:
> Simon Wilkinson <sxw@your-file-system.com> writes:
> 
> > We're not consistent about whether we release from trunk, or release
> > from a branch. This means that on some occasions the trunk has the tag,
> > and on others the branch. In a traditional git world, we would have
> > branched for 1.6.1, committed the changes necessary for 1.6.1 on that
> > branch, and then merged that branch back into the trunk. This final
> > merge step has the effect of making the 1.6.1 tag visible from both
> > branch and trunk, and so would cause both to git describe as
> > expected.
> 
> I'm very dubious about that merge back to trunk.  I'm not sure that
> development model really makes sense.  For better or worse, the trunk code
> and the stable branch code tends to diverge quickly and comprehensively,
> and we tend to apply separate fixes to trunk and to stable that are not
> equivalent.  Unless we make a reliable, regular habit of commiting -s ours
> merges in those cases, that merge from stable back to trunk can be a
> nightmare.
> 
> I also don't think it's necessary, in that I don't think that the 1.6.1
> tag needs to be exposed on the master branch.  What I do think is a
> serious problem is that it's not exposed on the stable branch, and there I
> don't really agree with the decision to create a separate branch off of
> stable to do 1.6 release stuff.  I sort of see how we got there, but I
> don't think it's wise.  (Of course, I'm not a gatekeeper now, so I can go
> on about how I would fix things without having to do any of the work....)
> 
> I think it makes sense to have stable branches, but approaching a stable
> point release I think the only things that should go into that branch are
> things that are going into that release, and I would not make any more
> branches.  When the release goes out, it's with that stuff.  If one
> absolutely has to create a sub-branch for some reason (such as a purely
> platform-specific release), then *that* sub-branch I would merge back into
> the stable branch to make the tag visible there.
> 
> On master, I would do something different: tag master with some sort of
> artifical version at the point that the stable branch splits off.  So, for
> example, when we split off a stable branch for 1.6, we could have tagged
> master at that point with something else.  There are a couple of possible
> strategies for what "something else" is:
> 
> * devel/1.7.0 or something similar.  This would mean that all packages
>   built from master would be 1.7.0+something versions (or 1.7.1 if one
>   ever incremented it, but I suspect that we just wouldn't).  This would
>   mean that the Windows-only release would have been 1.8, and when we
>   split it off we would tag master as devel/1.9.0, and so forth.
>   Basically, reserve the odd numbers for the master branch and as soon as
>   one branches for release, increment (via tag) the versions on master to
>   the next odd number.
> 
> * devel/1.6.99.  This avoids the problem of reserving odd version numbers
>   for packages off of master, while creating a weird artificial version
>   number that might be somewhat confusing.  But the same semantics would
>   apply; we would have tagged it devel/1.7.99 when we split off the 1.7
>   branch and so forth.
> 
> -- 
> Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info