[Gluster-Maintainers] Release scheduling and lifecycle of versions
Niels de Vos
ndevos at redhat.com
Tue Aug 2 18:57:12 UTC 2016
On Tue, Aug 02, 2016 at 01:19:59PM -0400, Dustin Black wrote:
> 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.
Nice, the v2 looks much better. I think with a few notes around it, all
users should be able to understand the schema.
Thanks!
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/5857625e/attachment.sig>
More information about the maintainers
mailing list