<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 2, 2016 at 3:06 AM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Aug 01, 2016 at 04:32:58PM -0400, Dustin Black wrote:<br>
> On Mon, Aug 1, 2016 at 3:06 PM, Dustin Black <<a href="mailto:dblack@redhat.com">dblack@redhat.com</a>> wrote:<br>
> ><br>
> > On Wed Jun 15 13:07:20 UTC 2016, Niels de Vos wrote:<br>
> > > On Wed, Jun 15, 2016 at 07:55:09AM -0500, Ric Wheeler wrote:<br>
> > > > On 06/14/2016 10:59 PM, Richard Fontana wrote:<br>
> > > > > On Tue, Jun 14, 2016 at 11:02:12PM -0400, Kaleb Keithley wrote:<br>
> > > > ><br>
> > > > > > But we don't need to guess, we can just ask our resident legal<br>
> > > > > > counsel, who wi ll tell us if there are any implications to<br>
> calling<br>
> > > > > > our planned long life cycle release of Community GlusterFS an "LTS<br>
> > > > > > release."<br>
> > > > > ><br>
> > > > > > Off hand I wouldn't expect there to be, but––<br>
> > > > > ><br>
> > > > > > Richard (and Ric) what, if any, implications are there? Should we<br>
> pick a different name?<br>
> > > > > No objection to "LTS" from me. I do not consider the 'S" to imply<br>
> > > > > "commercial support" if that's what the concern is (but even if it<br>
> > > > > did, that would not create any legal issue). I defer to Ric on<br>
> whether<br>
> > > > > there could be some non-legal concern around using "LTS".<br>
> > > > ><br>
> > > > > Richard<br>
> > > ><br>
> > > ><br>
> > > > The kernel calls its long term upstream versions "stable" releases or<br>
> > > > branches. LTS could stand for long term stable I suppose :)<br>
> > > ><br>
> > > > I don't think that we really care much, what we call the community<br>
> branches<br>
> > > > should be a community call. I would agree that avoiding "supported"<br>
> in the<br>
> > > > title is probably a good thing, but don't lose sleep over those terms.<br>
> > ><br>
> > > Oh, yes, great idea!<br>
> > ><br>
> > > LTS: Long Term Stable - 1 year of bugfixes<br>
> > > STS: Short Term Stable - 3 months of bugfixes<br>
> > ><br>
> > > We should use that :D<br>
> > > Niels<br>
> ><br>
> > How about "LTM: Long Term Maintenance" and "STM: Short Term Maintenance"?<br>
> It keeps the spirit without the possible conflicts or confusion related to<br>
> "support" or what the communities may (or may not) expect from the<br>
> similarity to Ubuntu's acronyms.<br>
<br>
</div></div>Nice idea. I think it is important to use different acronyms than users<br>
know from Ubuntu. Our release+maintenance schedule is probably different<br>
too. It prevents confusion.<br>
<div><div class="h5"><br>
<br>
> Building on the ASCII diagrams that Niels started (and continuing with the<br>
> "LTM" terminology that I've proposed and prefer), I would like to devise<br>
> graphics for the release website that explain the ongoing release schedule<br>
> in a way that doesn't need constant updating with release numbers and dates<br>
> (though we would likely maintain a separate table of actual and planned<br>
> releases).<br>
><br>
> I think it's best if this is broken into two sections: pre-3.8 and<br>
> post-3.8. The first section necessarily needs release numbers so that we<br>
> can properly document the retirement of the old release schedule. It would<br>
> look something like the below.<br>
><br>
> Current Releases up to 3.7:<br>
><br>
> +----+<br>
> 3.5 | *EOL at 3.8 release<br>
> +----+-----+<br>
> : 3.6 | *EOL at 3.9 release<br>
> +----------+-----+<br>
> : : 3.7 | *EOL at 3.10 release<br>
> +----------------+<br>
> : : :<br>
> : : :<br>
> +-----------------+<br>
> | 3.8 : :<br>
> +-----+-----------+<br>
> | 3.9 :<br>
> +-----+-----+<br>
> | 3.10<br>
> +-----+<br>
><br>
><br>
> The second section would graphically represent the ongoing 3-month release<br>
> schedule with every other release a LTM release. I think showing a roughly<br>
> 18 month spread is enough to get the point across well.<br>
><br>
><br>
> Release and Maintenance plan for 3.8+:<br>
><br>
> +-----------------------+<br>
> | Release 1 LTM |<br>
> +-----+-----+-----------+<br>
> : | R2 | :<br>
> : +-----------------------------+<br>
> : : | Release 3 LTM |<br>
> : : +-----+-----+-----------+<br>
> : : : | R4 | :<br>
> : : : +-----------------------------+<br>
> : : : : | Release 5 LTM |<br>
> : : : : +-----+-----+-----------+<br>
> : : : : : | R6 |<br>
> : : : : : +-----+<br>
> : : : : : :<br>
> 0 +3mos +6mos +9mos +12mos +18mos ...<br>
><br>
><br>
><br>
> Labeling the releases as numbers above is probably a problem, but I was<br>
> struggling to find a better way to denote the release progression. Ideas?<br>
><br>
> Obviously this will all look better and will more clearly illustrate the<br>
> release schedule when nicely rasterized, which I will work on.<br>
<br>
</div></div>Great! This looks good to me. It would be awesome if we can get it on<br>
the main <a href="http://gluster.org" rel="noreferrer" target="_blank">gluster.org</a> website.<br>
<br>
Thanks for looking into this,<br>
Niels<br>
</blockquote></div><br></div><div class="gmail_extra">Attached are first passes at the graphical versions of these diagrams in svg and png formats. Feedback is encouraged.</div></div>