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

[Jason Edgecombe]

On 06/15/2010 07:39 PM, Russ Allbery wrote:
> 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.
>
>    
Impressive and ambitious. I like it. I also like the time-based releases.

Is there a plan to keep the OS packaging up-to-date? Possibly have 
weekly or daily rpm, deb, and msi files generated?

I would be fine with being able to manually building packages from git.

Thanks,
Jason