<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-size:small">On Mon, Feb 27, 2017 at 1:06 PM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br></div></div></div></div></div></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Mon, Feb 27, 2017 at 11:25:11AM -0500, Shyam wrote:<br>
> On 02/27/2017 11:14 AM, Dustin Black wrote:<br>
> > I'm working on an update to the release schedule page [1] and have a<br>
> > question about the minor updates schedule for the active version.<br>
><br>
> Awesome, thanks!<br>
><br>
> ><br>
> > We have the 10th, 20th, and 30th of the month marked for minor updates<br>
> > to active versions. As of the 3.10 release the active versions should be<br>
> > only 3.8 and 3.10 (pre-3.8 version are all EOL and with this cycle there<br>
> > are no active STM versions).<br>
> ><br>
> > So for minor maintenance releases, which dates should be reflected for<br>
> > each of the 3.8 and 3.10 versions?<br>
><br>
> 3.10: 30th (as we released end of Feb. I am tying this to the month after<br>
> that)<br>
><br>
> ><br>
> > It would probably be best to update the webpage so that the section<br>
> > about minor updates isn't tied to version numbers so that it doesn't<br>
> > require an update with each release. Is there a standard way I could<br>
> > describe how we assign the update dates to the currently maintained<br>
> > versions?<br>
><br>
> This is a good idea, so that we/I do not tie this up as a month since the .0<br>
> was released.<br>
><br>
> My initial thought here would be,<br>
> 10th - LTM1<br>
> 20th - any open SMT<br>
> 30th - LTM2<br>
><br>
> This is to give time between each minor release, for any/all activity.<br>
> Unfortunately LTM1/2 will keep switching in this scheme.<br>
><br>
> Another, thought would be to do a fixed date for all LTMs. If a fix appears<br>
> in one LTM there is a good or even chance it will in the other, so possibly<br>
> fixing the LTM date can be a good idea, for the development/testing/upgrade<br>
> cycles. (and, as a result a fixed date for the STM as well.)<br>
><br>
> The downside of this is that, packaging of both LTMs fall around the same<br>
> time, possibly stretching the time required by this team to make the release<br>
> happen. If the packaging team is fine with this, the I would choose this<br>
> over different dates for the LTM.<br>
><br>
> In the latter scheme, we can choose 10th or the 30th for the LTM, possibly<br>
> the 10th as that is established for 3.8, for some duration and we can carry<br>
> that forward. Also, choose 20th for the STM.<br>
<br>
</div></div>I would say that once a LTM is released on the 10th or the 30th, that<br>
date will stay for the lifetime of the minor updates. This makes it more<br>
predictable for users of that LTM.<br>
<br>
We will have to update the page with the release dates (and approx. EOL)<br>
for all major versions anyway, in that table the day for the minor<br>
release is listed too. No need to have the version numbers in the<br>
describing paragraph(s).<br></blockquote><div><br></div><div>I have an update for the release table staged already; I'm just waiting to answer this question before the pull request.</div><div><br></div><div>The table right now doesn't have the minor update day in it directly -- that info is in the text and bullet points above the table. But, maybe this is a way to solve the issue. We can just put the minor update day right there in the table with the release version. Something like this:</div><div><br></div><font face="monospace, monospace">## Release Status<br><br>| Version | Status | Release Date | Maintenance Day | EOL Version | EOL Date |<br>| -------- |:---------------:|:---------------:|:---------------:|:-----------:|:----------:|<br>| 3.5 | EOL | 2014-05-07 | | 3.8 | 2016-06-14 |<br>| 3.6 | EOL | 2014-10-31 | | 3.9 | 2016-11-23 |<br>| 3.7 | EOL | 2015-05-15 | | 3.10 | 2017-02-24 |<br>| 3.8 | LTM | 2016-06-14 | 10th | 3.12 | |<br>| 3.9 | EOL | 2016-11-23 | | 3.10 | 2017-02-24 |<br>| **3.10** | **LTM** | **2017-02-27** | 30th | **n+4** | |<br>| *3.11* | *Planned STM* | *about 2017-05* | | 3.12 | |<br>| *3.12* | *Planned LTM* | *about 2017-08* | | *n+4* | |</font><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
Niels<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
><br>
> ><br>
> ><br>
> > [1] <a href="https://www.gluster.org/community/release-schedule/" rel="noreferrer" target="_blank">https://www.gluster.org/<wbr>community/release-schedule/</a><br>
> ><br>
> > Dustin Black, RHCA<br>
> > Senior Architect, Software-Defined Storage<br>
> > Red Hat, Inc.<br>
> > (o) <a href="tel:%2B1.212.510.4138" value="+12125104138">+1.212.510.4138</a> (m) <a href="tel:%2B1.215.821.7423" value="+12158217423">+1.215.821.7423</a><br>
> > <a href="mailto:dustin@redhat.com">dustin@redhat.com</a> <mailto:<a href="mailto:dustin@redhat.com">dustin@redhat.com</a>><br>
> ><br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > maintainers mailing list<br>
> > <a href="mailto:maintainers@gluster.org">maintainers@gluster.org</a><br>
> > <a href="http://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/maintainers</a><br>
> ><br>
> ______________________________<wbr>_________________<br>
> maintainers mailing list<br>
> <a href="mailto:maintainers@gluster.org">maintainers@gluster.org</a><br>
> <a href="http://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/maintainers</a><br>
</div></div></blockquote></div><br></div></div>