[OpenAFS] framework for future release model

[Derrick J Brashear]

Currently OpenAFS offers 2 trees, one development (the 1.5 series) and one 
stable (the 1.4 series), though this model has been strained as we have 
continued to support more versions of more platforms.

1) devel versus stable doesn't adequately characterize the trees when
the 1.5 tree is now mature on Windows and 1.4 is getting bugfixes only,
while no substantial stablization of new features for Unix platforms in
1.5 has happened yet.

2) tying major "stable" releases together has resulted in e.g. Tiger
support being delayed while we fixed major fileserver issues

3) But at the same time we have corporate and institutional users who
want some assurances that the release they are running is well-tested.

I offer this proposal, which obviously will need some tuning, as a 
framework future direction for OpenAFS

a) create 2 new branches to replace 1.5 and 1.4 (O and L)

b) for as many platforms as possible, implement auto release builds,
minimum nightly, maximum weekly.

c) designate a weekly time for autotagging. Each branch will have a
tag based on the number of days since the epoch (1 Nov 2000), for
instance this would be the O2304/L2304 release, tomorrow
O2305/L2305, etc.

d) when feasible, autotesting of autobuilt releases would be
implemented. any build passing the tests would be uploaded to the web site.

e) a per-platform consensus mechanism by which any set of people
designated as experts by the gatekeepers (or the elders, i don't have
strong feelings which is right) gets to designate a set of releases for
each platform, namely some or all of
  i) recommended
  ii) next best
  iii) recommended feature if some new feature has become available on the
       features branch but is not ready for general primetime

f) we will continue to work with contributors to improve web tools, so
releases can be done in a more trouble-free manner. In addition to the 
obvious web release page, things which would be nice to get would be
release RSS feeds, and if done right our standalone installers (e.g. not
.deb/.rpm) could use these to determine if new releases were available.

g) last, the web site is currently very developer/admin focused. We
should be splitting e.g.
www.openafs.org users (preserving working urls)
developer.openafs.org developers
admin.openafs.org administrators

and have content or at least layout tailored to each at each site. The 
elders have accepted a proposal from Sine Nomine for the donation of a new 
web site design with this in mind.

Derrick