<div dir="ltr"><div>It's a question of incentives. It's always "more cool" to implement features. If you have a feature freezes, but nothing can get merged before the 10 bugs have been fixed, you'll have more chance of people working on the bug fixes.</div><div>I distinctively remember the 2.0 situation where not many of us where tackling the 10 remaining tickets, and where we (in my opinion) really struggled to get the release out of the door.</div><div><br></div><div>Cheers,</div><div>N<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 12 Oct 2018 at 10:33, Ryan May <<a href="mailto:rmay31@gmail.com">rmay31@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Nelle,<div><br></div><div>I hear what you're saying about long-lived branches, but given that we do bug fix releases off that branch, it's going to be around for a long time any way; IMO the point is moot.</div><div><br></div><div>I'm also not sure that anything that impedes our ability to merge PRs (such as a feature freeze on master) is a good idea overall.</div><div><br></div><div>Ryan</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux <<a href="mailto:nelle.varoquaux@gmail.com" target="_blank">nelle.varoquaux@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>My two cents is that the branching process should not be happening to soon: can we do a feature freeze in master instead? Managing branches for long period of time can be a pain in the butt…<br></div><br><div>Cheers,</div><div>N<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 10 Oct 2018 at 18:50, Thomas Caswell <<a href="mailto:tcaswell@gmail.com" target="_blank">tcaswell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ok, so looking at my calendar, aiming to do 3.0.1 and 2.2.4 Nov 3-4 seems realistic. Even if we don't fix everything that has been reported, we have enough bug-fixes already in it will be worth it.<div><br></div><div>Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and a final release sometime in March?</div><div><br></div><div>Tom</div><div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <<a href="mailto:pmhobson@gmail.com" target="_blank">pmhobson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Agree with Ryan.<br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 10, 2018 at 11:36 AM Ryan May <<a href="mailto:rmay31@gmail.com" target="_blank">rmay31@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">I think those are reasonable. My only suggestion would be to try to increase the likelihood of hitting the schedule for 3.1 by starting the branching/RC process sooner. So maybe Feb or even Jan to start? It seems like part of our problem is that the stabilization/close out process takes longer than anticipated.</div></div><div dir="auto"><br></div><div dir="auto">Ryan</div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <<a href="mailto:tcaswell@gmail.com" target="_blank">tcaswell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Folks,<div><br></div><div>I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Tom</div></div>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="m_-4683445671875964902m_-7693835205465998530m_-5769874128453307206m_4461165567248125487m_6406456881250964653m_-1730252593645644075gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Ryan May<br><br></div></div></div>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div>
</blockquote></div></div></div>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-4683445671875964902gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Ryan May<br><br></div></div></div>
</blockquote></div>