[Gluster-Maintainers] Release scheduling and lifecycle of versions

Tue Aug 2 17:09:13 UTC 2016

On Tue, Aug 2, 2016 at 9:22 AM, Dustin Black <dblack at redhat.com> wrote:

> On Tue, Aug 2, 2016 at 3:06 AM, Niels de Vos <ndevos at redhat.com> wrote:
>
>> 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
>>
>
> Attached are first passes at the graphical versions of these diagrams in
> svg and png formats. Feedback is encouraged.
>
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
>
>
As we've already passed the 3.5 EOL, does it make sense to update this for
3.6 EOL?
- amye

-- 
Amye Scavarda | amye at redhat.com | Gluster Community Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160802/19e0124d/attachment.html>