[cdwg] Lustre maintenance releases

[Peter Bojanic]

Back to the future! Lustre 1.2, 1.4, 1.6, and 1.8 were the stable production releases, reserving the odd numbers for development releases. The practice was decidedly dropped as of Lustre 2.0.

Bojanic

On 2012-07-17, at 03:55 , John Carrier wrote:

> Chris,
> 
> A colleague asked if OpenSFS had considered the Linux kernel model of alternating even numbered feature releases with odd numbered stable maintenance releases.  He said this made it easier for users to know when a version would be usable for production.
> 
> If we apply this model to your proposal (18m maintenance releases, 3y total support for each maintenance branch), then we would need to reduce the number of feature releases to just one, 9months after the maintenance release.   Is that too long between releases? Does this model prevent additions of new features in the odd numbered releases?
> 
> Thanks,
> 
> --jc
> 
> 
> -----Original Message-----
> From: cdwg-bounces at lists.opensfs.org [mailto:cdwg-bounces at lists.opensfs.org] On Behalf Of Christopher J. Morrone
> Sent: Friday, July 13, 2012 11:21 AM
> To: cdwg at lists.opensfs.org
> Subject: Re: [cdwg] Lustre maintenance releases
> 
> Sorry, I had my second timeline dates wrong.  See attached lustre_maintenance_timeline2.png for the correction.
> 
> On 07/13/2012 10:59 AM, Christopher J. Morrone wrote:
>> 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
>> 
> 
> 
> _______________________________________________
> cdwg mailing list
> cdwg at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org