[Gluster-Maintainers] Release scheduling and lifecycle of versions
Dustin Black
dblack at redhat.com
Tue Aug 2 17:19:59 UTC 2016
On Tue, Aug 2, 2016 at 1:09 PM, Amye Scavarda <amye at redhat.com> wrote:
>
>
> 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
>
I'd argue that showing one EOL release back might be good reference. Then
once 3.10 is released, the "legacy" graphic can be retired completely.
Attached png copies of v2 of each of these, with some more clear graphics
and the "release" numbers replaced with roman numerals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160802/5acb3d93/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Gluster Pre-3.8 Release Cycle v2.png
Type: image/png
Size: 14252 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160802/5acb3d93/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Gluster Post-3.8 Release Cycle v2.png
Type: image/png
Size: 15209 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160802/5acb3d93/attachment-0003.png>
More information about the maintainers
mailing list