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