> I think that various release engineers here and there have developed a
> attack on this general problem. Possibly, it would help NetBSD.
> The theory goes like this...
> 
> In general the original problem is that the project is trying to make a
> release out of a development code branch. (Or trying to develop on a
> release, the point being you need more than one code branch.)
> 
> The solution is to anticipate a release and split the code off into the
> release branch and the development branch. Bug _fixes_ (at least, those
> that don't include major rewrites) go into _both_ branches. You should
> actually continue to apply bug fixes even after the release date. (You
> can release more often with this scheme, and you can always put an
> absolute freeze on the _previous_ release to get a completely static
> baseline. The previous release with this system is likely to be a lot
> newer than the most recent release is now.)
> 
> New development continues in the development branch.

Actually, this is almost _exactly_ what's done with the NetBSD CVS
tree.  (In fact, that model occurred to us pretty early on...  no
later than 1.0, if I recall.)  The difference is that after the code
base is mostly frozen, rather than committing fixes to both the trunk
and the release branch, they're committed to the trunk and a pull-up
request is sent to the person playing release engineer.

While the release process is in progress, -current follows the release
branch.  It goes back to following the main development branch a while
after the release.

For instance the NetBSD 1.2 branch was a created a while before 1.2
was release.  -current followed it until 1.2 was released, then went
back to the development branch.  pull-up requests continued to happen,
however, and changes continued to be pulled up to the 1.2 branch.  1.2
+ those pull-ups are what constitute the 1.2.1 code base.

In general, new features were not pulled up, only bug fixes (for some
definition thereof 8-).

Of course, pull-up requests decrease as the source tree moves further
and further from the last release.


In reality, for various reasons, the RE process for 1.2 didn't go very
smoothly, and I have no clue why 1.2.1 hasn't been formally released
yet (has it?  i dunno, and am behind on my mail).  However, in theory,
the process works exactly as described above.

To my mind, it'd be nice if there were a way to get a snapshot of the
'last release branch' every day via sup or FTP, and if bug fixes
continued to happen in it, but the resources that that would require
are probably prohibitive for a project the size of NetBSD.



cgd