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
signature.asc
Description: PGP signature
_______________________________________________ maintainers mailing list [email protected] http://www.gluster.org/mailman/listinfo/maintainers
