<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 14, 2016 at 5:38 PM, Pranith Kumar Karampuri <span dir="ltr">&lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>hi,<br></div>        Some of our managers were cautioning us to use the term LTS with care as it means something else in ubuntu world where LTS is how they make money by providing support. I see that quite a few open source projects have similar release cadence but they don&#39;t call them LTS. They call them stable branches. May be it makes sense to call them stable branches and feature branches rather than LTS/non-LTS? Suggestions for other names is welcome. At least we need to clear any confusion that we are not looking to make money out of the LTS branches :-D. Different name for the branches is preferable.<br></div><div class="gmail_extra"><br></div></blockquote><div>This is what I was cautioning around:</div><div><br></div><div><span style="font-size:12.8px">## Results of several rounds of discussion</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">It seems that a 3 month release cycle is the most attractive. Each</span><br style="font-size:12.8px"><span style="font-size:12.8px">alternating major release would be a Long-Term-Support (LTS) one, the</span><br style="font-size:12.8px"><span style="font-size:12.8px">others are short living versions for users that are eager to test out a</span><br style="font-size:12.8px"><span style="font-size:12.8px">new feature. </span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">We should use a different word to make clear what we&#39;re actually offering. I am fine with &#39;stable&#39;, &#39;currently receiving patches&#39;, whatever. The S in Support, I feel, should be a downstream concern, and I am not sure we are making that clear within ourselves. </span></div><div><br></div><div><span style="font-size:12.8px">-- a </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Wed, Jun 15, 2016 at 1:06 AM, Amye Scavarda <span dir="ltr">&lt;<a href="mailto:amye@redhat.com" target="_blank">amye@redhat.com</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="h5"><div dir="ltr"><br><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Sat, Jun 11, 2016 at 10:55 AM, Atin Mukherjee <span dir="ltr">&lt;<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
<br>
On 06/10/2016 07:51 AM, Niels de Vos wrote:<br>
</span><div><div>&gt; After several weeks of discussions on this list, in the weekly meeting<br>
&gt; and ad-hoc IRC chats, I have come to the following understanding of the<br>
&gt; release schedule, lifecyle and minor updates.<br>
&gt;<br>
&gt; ## What we want to address<br>
&gt;<br>
&gt; 1. regular releases, predictable cycle for users and other projects<br>
&gt; 2. faster &quot;go to market&quot; with new features, receive feedback from users<br>
&gt; 3. stable version(s) for &#39;happily running, no risk&#39; deployments<br>
&gt; 4. active releases can do monthly bugfix updates (see backport criteria)<br>
&gt;<br>
&gt;<br>
&gt; ## Results of several rounds of discussion<br>
&gt;<br>
&gt; It seems that a 3 month release cycle is the most attractive. Each<br>
&gt; alternating major release would be a Long-Term-Support (LTS) one, the<br>
&gt; others are short living versions for users that are eager to test out a<br>
&gt; new feature.<br>
&gt;<br>
&gt;<br>
&gt; ## Three stable/LTS versions, 1.5 years of bugfixes<br>
&gt;<br>
&gt; In dates and versions, this results in something like:<br>
&gt;<br>
&gt;  3.5: EOL when 3.8 goes GA (2016-06)<br>
&gt;  3.6: EOL when 3.9 goes GA (2016-09)<br>
&gt;  3.7: EOL when 3.10 goes GA (2016-12)<br>
&gt;  3.8 [LTS]: EOL when 3.14 goes GA (2017-12)<br>
&gt;  3.9: EOL when 3.10 goes GA (2016-12)<br>
&gt;  3.10 [LTS]: EOL when 3.16 goes GA (2018-06)<br>
&gt;  3.11: EOL when 3.12 goes GA (2017-06)<br>
&gt;  3.12 [LTS]: EOL when 3.18 goes GA (2018-12)<br>
&gt;  3.13: EOL when 3.13 goes GA<br>
&gt;  3.14 [LTS]: EOL when 3.20 goes GA<br>
&gt;<br>
&gt;  (one of the 3.x releases will be called 4.0, I do not want to predict<br>
&gt;   when that is ready and leave that up to the 4.0 team)<br>
&gt;<br>
&gt; And, &#39;visualized&#39;:<br>
&gt;<br>
&gt;  ----.<br>
&gt;  3.5 |<br>
&gt;  -----------.<br>
&gt;         3.6 |<br>
&gt;  ------------------.<br>
&gt;                3.7 |<br>
&gt;  ----------------------------------------------.<br>
&gt;      |                   3.8                   |<br>
&gt;      &#39;------.------.---------------------------&#39;<br>
&gt;             | 3.9  |<br>
&gt;      :      &#39;------+-----------------------------------------.<br>
&gt;                    |                   3.10                  |<br>
&gt;      :      :      &#39;------.------.---------------------------&#39;<br>
&gt;                           | 3.11 |<br>
&gt;      :      :      :      &#39;------+-------------------------------------<br>
&gt;                                  |                   3.12<br>
&gt;      :      :      :      :      &#39;------.------.-----------------------<br>
&gt;                                         | 3.13 |<br>
&gt;      :      :      :      :      :      &#39;------+-----------------------<br>
&gt;                                                |                   3.14<br>
&gt;      :      :      :      :      :      :      &#39;------.------.---------<br>
&gt;                                                       | 3.15 |<br>
&gt;      :      :      :      :      :      :      :      &#39;------+---------<br>
&gt;                                                              |     3.16<br>
&gt;      :      :      :      :      :      :      :      :      &#39;---------<br>
&gt;<br>
&gt;   2016-06   :   2016-12   :   2017-06   :   2017-12   :   2018-06<br>
&gt;<br>
&gt;          2016-09       2017-03       2017-09       2018-03<br>
&gt;<br>
&gt;<br>
&gt; ## Two stable/LTS versions, 1 year of bugfixes<br>
&gt;<br>
&gt; Looking at the diagram makes me wonder if this really is a sane approach<br>
&gt; that we can promise to our users. When 3.13 (or 4.x) gets released, we<br>
&gt; would have 4 active versions. At the moment we are already struggling<br>
&gt; with three active versions, so I doubt we can really do that. So, here a<br>
&gt; variation, and my suggestion to keep two stable releases instead of<br>
&gt; three:<br>
&gt;<br>
&gt;  3.5: EOL when 3.8 goes GA (2016-06)<br>
&gt;  3.6: EOL when 3.9 goes GA (2016-09)<br>
&gt;  3.7: EOL when 3.10 goes GA (2016-12)<br>
&gt;  3.8 [LTS]: EOL when 3.12 goes GA (2017-06)<br>
&gt;  3.9: EOL when 3.10 goes GA (2016-12)<br>
&gt;  3.10 [LTS]: EOL when 3.14 goes GA (2017-12)<br>
&gt;  3.11: EOL when 3.12 goes GA (2017-06)<br>
&gt;  3.12 [LTS]: EOL when 3.16 goes GA (2018-06)<br>
&gt;  3.13: EOL when 3.13 goes GA<br>
&gt;  3.14 [LTS]: EOL when 3.18 goes GA<br>
<br>
</div></div>+1<br>
<span><br>
&gt;<br>
&gt;  (one of the 3.x releases will be called 4.0, I do not want to predict<br>
&gt;   when that is ready and leave that up to the 4.0 team)<br>
<br>
</span>Most probably it&#39;d be around 3.12ish as per my prediction.<br>
<div><div><br>
&gt;<br>
&gt;  ----.<br>
&gt;  3.5 |<br>
&gt;  -----------.<br>
&gt;         3.6 |<br>
&gt;  ------------------.<br>
&gt;                3.7 |<br>
&gt;  --------------------------------.<br>
&gt;      |            3.8            |<br>
&gt;      &#39;------.------.-------------&#39;<br>
&gt;             | 3.9  |<br>
&gt;      :      &#39;------+---------------------------.<br>
&gt;                    |           3.10            |<br>
&gt;      :      :      &#39;------.------.-------------&#39;<br>
&gt;                           | 3.11 |<br>
&gt;      :      :      :      &#39;------+---------------------------.<br>
&gt;                                  |           3.12            |<br>
&gt;      :      :      :      :      &#39;------.------.-------------&#39;<br>
&gt;                                         | 3.13 |<br>
&gt;      :      :      :      :      :      &#39;------+-----------------------<br>
&gt;                                                |            3.14<br>
&gt;      :      :      :      :      :      :      &#39;------.------.---------<br>
&gt;                                                       | 3.15 |<br>
&gt;      :      :      :      :      :      :      :      &#39;------+---------<br>
&gt;                                                              |     3.16<br>
&gt;      :      :      :      :      :      :      :      :      &#39;---------<br>
&gt;<br>
&gt;   2016-06   :   2016-12   :   2017-06   :   2017-12   :   2018-06<br>
&gt;<br>
&gt;          2016-09       2017-03       2017-09       2018-03<br>
&gt;<br>
&gt;<br>
&gt; Providing bugfixes for a LTS release for a year seems like a suitable<br>
&gt; middle road. If other projects/organizations want to support a certain<br>
&gt; version longer, they can do so themselves or step up and contribute a<br>
&gt; maintainer to our community.<br>
&gt;<br>
&gt;<br>
&gt; I expect that the number of patches in the stable releases get reduced A<br>
&gt; LOT compared to the current 3.7 version. With regular releases there<br>
&gt; should not be a need to backport complex patches or features.<br>
&gt; Maintainance of a stable release should be a very boring and simple<br>
&gt; task.<br>
<br>
</div></div>What would be the frequency of the z stream releases for LTS? Should we<br>
keep it flexible and decide based on the volume of incoming fixes?<br>
<span><br>
&gt;<br>
&gt; Any suggestions for modifications or clarification needed before this<br>
&gt; can be transferred to a good looking webpage (by Amye?) on <a href="http://gluster.org" rel="noreferrer" target="_blank">gluster.org</a>?<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Niels<br></span></blockquote></div><br clear="all"><div><br></div></div></div><div>So I&#39;ve caught up on (I think) - most of the discussions that have been happening in different places but I&#39;m still missing a critical piece in here.</div><div>LTS means Long Term Support, and Niels outlines this. </div><div>Are we currently providing, as <a href="http://gluster.org" target="_blank">gluster.org</a>, something that we would declare &#39;S&#39; in LTS? </div><div>How does that change/improve/decline with this new proposed process? We should discuss before moving this to -users/-devel. </div><div><br></div><div>I&#39;m also with Kaleb on his comments about how we establish a schedule. </div><div>-- amye </div><span><font color="#888888"><div><br></div><div data-smartmail="gmail_signature"><div dir="ltr">Amye Scavarda | <a href="mailto:amye@redhat.com" target="_blank">amye@redhat.com</a> | Gluster Community Lead</div></div>
</font></span></div></div>
<br></div></div><span class="">_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/maintainers</a><br>
<br></span></blockquote></div><span class=""><font color="#888888"><br><br clear="all"><br>-- <br><div data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Amye Scavarda | <a href="mailto:amye@redhat.com" target="_blank">amye@redhat.com</a> | Gluster Community Lead</div></div>
</div></div>