[cdwg] Lustre maintenance releases

[Cory Spitz]

I like the direction of this thread and there are some good ideas for a
long term model.  Thanks, Chris, for making your proposal to the list.
I promised on the last CDWG call that I would send mail to the list to
clarify the idea that I had to get us to our future model.  Apologies
for the lateness.

We seemed to reach a consensus that b2_4 ought to be designated as a
maintenance branch after the initial 2.4 feature release.  What I was
trying to say over the phone was that if we do agree on that and if we
nominally wait 3 months to spool up bugfixes to 2.4, it will arrive
around Q2'13 if everything stays on-track.  And that's over a year away
from the original 2.1.x maintenance release and an awful lot of change
for folks to take between 2.1.x and 2.4.1, which seemed like a concern
for people on the call.

I was only suggesting that we could create a 2.3.1 release as a quick
stability catch-up for the feature stream and as a stepping stone to get
to a future 2.4.1.  We would have to state up-front that there would be
no 2.3.2.  It was merely a proposal to mitigate the risk of a big
catch-up to 2.4.x.  If we don't feel that it is worthwhile to address
that issue, then I suggest that we get started on formalizing the long
term maintenance branch and release model.

To recap, here is what I was thinking for the maintenance stream:

             2012                            2013
  Q1      Q2      Q3      Q4      Q1      Q2      Q3      Q4
2.1.1 -> 2.1.2 -> 2.1.3
 2.2
                  2.3 -> 2.3.1
                                 2.4 -> 2.4.1 -> 2.4.2
                                                  2.5

I think that the above agrees with what Chris has proposed for the short
term, aside from the quick blip of 2.3.1.

Thanks,
-Cory

On 07/13/2012 12:59 PM, 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