[OpenAFS] 1.6 and post-1.6 OpenAFS branch management and schedule

[Russ Allbery]

Hello folks,

This was discussed at the AFS and Kerberos Best Practices Workshop, but
we've been remiss in sending it out via e-mail.  Apologies for that; all
three of the gatekeepers have been insanely busy for a variety of other
reasons.

We're about to start the OpenAFS 1.6 release process.  There will be at
least one more release in the 1.5 series, but we're planning on branching
the 1.6 release branch relatively soon and then starting release
candidates for broader testing, aiming for a 1.6 release within the next
few months.

After 1.6, we currently have the following plan.  This is definitely open
for discussion and is not set in stone, but it's our current intention.
Please send feedback (preferrably to openafs-devel, since I believe that's
where most of the discussion will be).

We have the following major work that we hope we can merge this calendar
year:

* Windows IFS (the native file system implementation)
* rxk5
* Object storage (RxOSD)
* Rx UDP performance improvements
* PTS authentication name extensions
* Extended callbacks

The following major work we hope to merge in the first half of 2011:

* rxgk with Kerberos v5, X.509, and SCRAM support
* Protection of anonymous connections
* Protection of the server to client callback connection
* Server-coordinated byte-range locking

Obviously, we'll accept any other work that is completed and ready to
merge as well; those are just the major things that we know are in
progress and roughly when they're expected to be done.

The combination of ongoing SMB problems with the current Windows client
and the substantial improvements offered by the Windows IFS client, as
well as community feedback on that client and the current development and
testing state of that work, leads us to believe that making a fast 1.8
release after 1.6, merging Windows IFS, is worthwhile.  Therefore,
post-1.6, our release plan is as follows:

1. Create a 1.7 branch based on 1.6 at the same time that we release
   1.6.0.

2. Set up the 1.7 branch as a tracking branch for 1.6.  This means that
   1.7 will automatically get any commits that are applied to 1.6.

3. Submit the Windows IFS work through Gerrit, and merge it into master
   and onto the 1.7 branch.  We just had a long discussion in Jabber about
   how best to do this merge, and I don't want to assume any outcome for
   that discussion yet; we're still figuring out what branches the Gerrit
   submissions will go to first and how they'll be reviewed.  But at the
   end of this process, we'll have the Windows IFS code in both master and
   on a 1.7 branch, and the 1.7 branch will be exactly 1.6 + Windows IFS.

4. While this merge is in progress, work will continue on master as
   normal, possibly including development releases.  Develoment releases
   from master will be a 1.9 series starting with 1.9.0.  In other words,
   we're reserving 1.7 and 1.8 for 1.6 + Windows IFS, but we're not
   delaying any other work.  Other work should be able to continue in
   parallel in the 1.9 series.

5. Release 1.7.0 from the 1.7 branch for testing when the code is all
   merged.

6. Further changes to fix problems discovered after 1.7.0 will go into
   master first and then be pulled up to 1.7 following our normal
   process.  1.7 will also continue to automatically get merges of all
   commits put into 1.6.

7. Once 1.7 is tested and determined to be stable, release 1.8 from the
   1.7 branch and retire the 1.6 branch, since 1.8 will be exactly 1.6
   plus Windows IFS.  Our target date for this release is September 2010.

8. Continue development towards 1.10 on master, with 1.9 testing releases
   as desired.  The goal for 1.10 is to incorporate all of the changes in
   the list above marked "hopefully this calendar year."  However, the
   intention is for 1.10 to be a time-based release.  Whatever is merged
   and ready to be shipped as of December of 2010 is what will be in 1.10.

9. In December 2010, branch master to a 1.10 branch and start doing
   release candidates.  Development will continue on master for a release
   that, if we merge the features in the second set above, we will be
   calling 2.0.  The intent is for this to also be a time-based release,
   including whatever is ready to ship as of June of 2011.

The initial target date for 2.0 release candidates is June of 2011.

This means that for a time we'll have at least three active branches: the
1.6 release branch, the 1.7 branch which is 1.6 plus Windows IFS, and
master.

There is some feeling that we're also likely to need to maintain the
stable 1.4 branch a while into the life span of 1.6 and possibly make a
few more 1.4 releases even after 1.6.0 is out, at least for UNIX (the 1.4
branch is already not recommended for Windows).  Someone else should speak
to Mac OS X from the 1.4 branch.  However, the fewer branches we have, the
less work there is, so of course we'd like to reduce the number of
maintained branches as soon as we can.

Discussion?  Comments?  Feedback?  Once we've revised and firmed up this
plan, we'll send something to openafs-announce.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>