[cdwg] Lustre maintenance releases

[Andreas Dilger]

On 2012-07-13, at 11:59 AM, Christopher J. Morrone wrote:
> 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.

One minor note is that the dates on this second diagram are incorrect.  It shows 2.1 starting in March 2013, when that is actually the start of 2.4.  Everything needs to be back-dated 18 months so that 2.1 starts in Sept 2011, but is otherwise fine.

> 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
> 
> <lustre_releases.png><lustre_maintenance_timeline.png>_______________________________________________
> cdwg mailing list
> cdwg at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org


Cheers, Andreas
--
Andreas Dilger                       Whamcloud, Inc.
Principal Lustre Engineer            http://www.whamcloud.com/