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