[OpenAFS] buildbot and packages

[Russ Allbery]

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