[cdwg] Lustre maintenance releases

[Christopher J. Morrone]

Hi folks,

Attached is a graphic (lustre_releases.png) that I've made to try to 
illustrate the difference between "feature" and "maintenance" releases. 
  Note that this doesn't fully represent every tag and branch in the 
repo, but this should be all that most end users and non-developer folks 
should likely need to concern themselves with.

The horizontal arrow represents the "master" branch of lustre, on which 
we land both bug fixes and all new features.  We follow a development 
cadence of 6 months between major tags on master.  We've been calling 
those tags "feature" releases.  Perhaps we need to change that 
terminology in the future to reduce confusion.

The vertical arrows represent the "maintenance" branches.  Code changes 
along the vertical branches should ONLY be bug fixes.  This is the place 
to go if you are an institution or vendor that plans to have a system 
that needs to be stable for 18 months, 3 years, whatever, and you are 
not planning to do and significant OS upgrades.  I know we have systems 
like that here at LLNL, and there are other systems out there that 
operate that way.

The "maintenance" branch is where we point the user that just wants a 
stable lustre, and isn't interested in the latest bleeding-edge features.

We are doing this today.  The only part of my diagram that has not been 
decided is if we should officially declare that a new maintenance branch 
will begin on every third feature release.  So the "18 months" is not 
official yet, and we don't yet know if "b2_4" will be the next 
maintenance branch.

I would like us to decide on that rather soon, so we can all begin 
shifting our internal schedules to align with the 2.4 release in March 
2013 (or whatever release we decide to designate).

After that, an obvious question might be: "how long lived are these 
branches?".  I am going to propose, to start the conversation, that we 
make the stated lifetime of the maintenance branches 3 years.  That 
would make the timeline for stable maintenance branches look like the 
attached timeline graphic (lustre_maintenance_timeline.png).  A new 
maintenance branch would start every 18 months, and live for 36 months.

If we maintain our rule that a maintenance branch receives only bug 
fixes, after the first 18 months I suspect that a maintenance branch's 
required effort will have tapered off quite a bit, so hopefully 
overlapping the supported stable maintenance branches will not prove an 
unacceptable burden on the development community.

This proposal would mean that at any point in time there are basically 
three major branches that the general public will be aware of:

   Current stable maintenance branch
   Previous stable maintenance branch
   Development branch (master)

And frankly, most end users will only look at one of the maintenance 
branches.  Anyone not already using lustre should always pick the 
current stable maintenance branch.  Anyone running an older machine that 
has no plans to upgrade their OS will stick with the maintenance branch 
that they are already on.

And of course, if you absolutely need some new feature in lustre, you 
can always pick up the latest feature release from master.  But you do 
that knowing that your upgrade path is always horizontally on the master 
branch until you reach the next maintenance release that forks off 
vertically (as represented in the lustre_releases.png).

Chris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lustre_releases.png
Type: image/png
Size: 30403 bytes
Desc: not available
URL: <http://lists.opensfs.org/pipermail/cdwg-opensfs.org/attachments/20120713/27392c15/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lustre_maintenance_timeline.png
Type: image/png
Size: 21416 bytes
Desc: not available
URL: <http://lists.opensfs.org/pipermail/cdwg-opensfs.org/attachments/20120713/27392c15/attachment-0003.png>