On Tue, Aug 02, 2016 at 01:19:59PM -0400, Dustin Black wrote: > On Tue, Aug 2, 2016 at 1:09 PM, Amye Scavarda <[email protected]> wrote: > > > > > > > On Tue, Aug 2, 2016 at 9:22 AM, Dustin Black <[email protected]> wrote: > > > >> On Tue, Aug 2, 2016 at 3:06 AM, Niels de Vos <[email protected]> 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 <[email protected]> > >>> 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 > >> [email protected] > >> 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 | [email protected] | 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
signature.asc
Description: PGP signature
_______________________________________________ maintainers mailing list [email protected] http://www.gluster.org/mailman/listinfo/maintainers
