[Gluster-Maintainers] Release scheduling and lifecycle of versions

[Niels de Vos]

On Mon, Aug 01, 2016 at 04:32:58PM -0400, Dustin Black wrote:
> On Mon, Aug 1, 2016 at 3:06 PM, Dustin Black <dblack at redhat.com> wrote:
> >
> > On Wed Jun 15 13:07:20 UTC 2016, Niels de Vos wrote:
> > > On Wed, Jun 15, 2016 at 07:55:09AM -0500, Ric Wheeler wrote:
> > > > On 06/14/2016 10:59 PM, Richard Fontana wrote:
> > > > > On Tue, Jun 14, 2016 at 11:02:12PM -0400, Kaleb Keithley wrote:
> > > > >
> > > > > > But we don't need to guess, we can just ask our resident legal
> > > > > > counsel, who wi ll tell us if there are any implications to
> calling
> > > > > > our planned long life cycle release of Community GlusterFS an "LTS
> > > > > > release."
> > > > > >
> > > > > > Off hand I wouldn't expect there to be, but––
> > > > > >
> > > > > > Richard (and Ric) what, if any, implications are there? Should we
> pick a different name?
> > > > > No objection to "LTS" from me. I do not consider the 'S" to imply
> > > > > "commercial support" if that's what the concern is (but even if it
> > > > > did, that would not create any legal issue). I defer to Ric on
> whether
> > > > > there could be some non-legal concern around using "LTS".
> > > > >
> > > > > Richard
> > > >
> > > >
> > > > The kernel calls its long term upstream versions "stable" releases or
> > > > branches. LTS could stand for long term stable I suppose :)
> > > >
> > > > I don't think that we really care much, what we call the community
> branches
> > > > should be a community call. I would agree that avoiding "supported"
> in the
> > > > title is probably a good thing, but don't lose sleep over those terms.
> > >
> > > Oh, yes, great idea!
> > >
> > >    LTS: Long Term Stable - 1 year of bugfixes
> > >    STS: Short Term Stable - 3 months of bugfixes
> > >
> > > We should use that :D
> > > Niels
> >
> > How about "LTM: Long Term Maintenance" and "STM: Short Term Maintenance"?
> It keeps the spirit without the possible conflicts or confusion related to
> "support" or what the communities may (or may not) expect from the
> similarity to Ubuntu's acronyms.

Nice idea. I think it is important to use different acronyms than users
know from Ubuntu. Our release+maintenance schedule is probably different
too. It prevents confusion.


> Building on the ASCII diagrams that Niels started (and continuing with the
> "LTM" terminology that I've proposed and prefer), I would like to devise
> graphics for the release website that explain the ongoing release schedule
> in a way that doesn't need constant updating with release numbers and dates
> (though we would likely maintain a separate table of actual and planned
> releases).
> 
> I think it's best if this is broken into two sections: pre-3.8 and
> post-3.8. The first section necessarily needs release numbers so that we
> can properly document the retirement of the old release schedule. It would
> look something like the below.
> 
> Current Releases up to 3.7:
> 
> +----+
>  3.5 | *EOL at 3.8 release
> +----+-----+
>      : 3.6 | *EOL at 3.9 release
> +----------+-----+
>      :     : 3.7 | *EOL at 3.10 release
> +----------------+
>      :     :     :
>      :     :     :
>      +-----------------+
>      | 3.8 :     :
>      +-----+-----------+
>            | 3.9 :
>            +-----+-----+
>                  | 3.10
>                  +-----+
> 
> 
> The second section would graphically represent the ongoing 3-month release
> schedule with every other release a LTM release. I think showing a roughly
> 18 month spread is enough to get the point across well.
> 
> 
>  Release and Maintenance plan for 3.8+:
> 
>  +-----------------------+
>  | Release 1 LTM         |
>  +-----+-----+-----------+
>  :     | R2  |           :
>  :     +-----------------------------+
>  :     :     | Release 3 LTM         |
>  :     :     +-----+-----+-----------+
>  :     :     :     | R4  |           :
>  :     :     :     +-----------------------------+
>  :     :     :     :     | Release 5 LTM         |
>  :     :     :     :     +-----+-----+-----------+
>  :     :     :     :     :     | R6  |
>  :     :     :     :     :     +-----+
>  :     :     :     :     :           :
>  0   +3mos +6mos +9mos +12mos      +18mos      ...
> 
> 
> 
> Labeling the releases as numbers above is probably a problem, but I was
> struggling to find a better way to denote the release progression. Ideas?
> 
> Obviously this will all look better and will more clearly illustrate the
> release schedule when nicely rasterized, which I will work on.

Great! This looks good to me. It would be awesome if we can get it on
the main gluster.org website.

Thanks for looking into this,
Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160802/2f94f97c/attachment.sig>