Folks,
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.
Thoughts?
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181009/59e56906/attachment.html>
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.
Ryan
On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <tcaswell at gmail.com> wrote:
Folks,
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.Thoughts?
Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page
--
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181010/71018e27/attachment.html>
Agree with Ryan.
On Wed, Oct 10, 2018 at 11:36 AM Ryan May <rmay31 at gmail.com> wrote:
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.Ryan
On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <tcaswell at gmail.com> wrote:
Folks,
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.Thoughts?
Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181010/75e4bf7e/attachment.html>
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.
Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and a
final release sometime in March?
Tom
On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <pmhobson at gmail.com> wrote:
Agree with Ryan.
On Wed, Oct 10, 2018 at 11:36 AM Ryan May <rmay31 at gmail.com> wrote:
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.Ryan
On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <tcaswell at gmail.com> wrote:
Folks,
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.Thoughts?
Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181010/db382a23/attachment-0001.html>
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?
Cheers,
N
On Wed, 10 Oct 2018 at 18:50, Thomas Caswell <tcaswell at gmail.com> wrote:
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.Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and
a final release sometime in March?Tom
On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <pmhobson at gmail.com> wrote:
Agree with Ryan.
On Wed, Oct 10, 2018 at 11:36 AM Ryan May <rmay31 at gmail.com> wrote:
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.Ryan
On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <tcaswell at gmail.com> >>> wrote:
Folks,
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.Thoughts?
Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181010/a5bc7df7/attachment.html>
Nelle,
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.
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.
Ryan
On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux <nelle.varoquaux at gmail.com> wrote:
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?Cheers,
NOn Wed, 10 Oct 2018 at 18:50, Thomas Caswell <tcaswell at gmail.com> wrote:
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.Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and
a final release sometime in March?Tom
On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <pmhobson at gmail.com> wrote:
Agree with Ryan.
On Wed, Oct 10, 2018 at 11:36 AM Ryan May <rmay31 at gmail.com> wrote:
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.Ryan
On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <tcaswell at gmail.com> >>>> wrote:
Folks,
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.Thoughts?
Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page
--
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181012/ec799a60/attachment.html>
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.
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.
Cheers,
N
On Fri, 12 Oct 2018 at 10:33, Ryan May <rmay31 at gmail.com> wrote:
Nelle,
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.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.Ryan
On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux <nelle.varoquaux at gmail.com> > wrote:
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?Cheers,
NOn Wed, 10 Oct 2018 at 18:50, Thomas Caswell <tcaswell at gmail.com> wrote:
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.Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary
and a final release sometime in March?Tom
On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <pmhobson at gmail.com> wrote:
Agree with Ryan.
On Wed, Oct 10, 2018 at 11:36 AM Ryan May <rmay31 at gmail.com> wrote:
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.Ryan
On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <tcaswell at gmail.com> >>>>> wrote:
Folks,
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.Thoughts?
Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181012/4ffdd356/attachment.html>
I have no problem with branching 3.1 early (we are already managing
backports into the very-long-lived 2.2.x branch and that doesn't seem to be
a problem at all). I'm not sure why you'd want to prevent feature merges
to master for a month. It's not the end of the world if 3.1 takes 45 days
or even 60 to be released instead of 30...
Antony
On Fri, Oct 12, 2018 at 8:54 PM Nelle Varoquaux <nelle.varoquaux at gmail.com> wrote:
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.
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.Cheers,
NOn Fri, 12 Oct 2018 at 10:33, Ryan May <rmay31 at gmail.com> wrote:
Nelle,
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.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.Ryan
On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux < >> nelle.varoquaux at gmail.com> wrote:
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?Cheers,
NOn Wed, 10 Oct 2018 at 18:50, Thomas Caswell <tcaswell at gmail.com> wrote:
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.Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary
and a final release sometime in March?Tom
On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <pmhobson at gmail.com> wrote:
Agree with Ryan.
On Wed, Oct 10, 2018 at 11:36 AM Ryan May <rmay31 at gmail.com> wrote:
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.Ryan
On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <tcaswell at gmail.com> >>>>>> wrote:
Folks,
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.Thoughts?
Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181013/dd081cf8/attachment.html>
I am also not worried about forking early. Meeseeksdev makes it pretty
easy to manage backports. I am cautious about over-learning from the 2.0
release process. Mike and I drastically under-estimated the amount of work
that would be required to begin with and I ended up being the bottle neck
on a number of issues at the end.
I think we are too distributed with too many volunteer devs to freeze
master for a few weeks (on the other hand, freezing master is definitely
how we do this on my day-job projects!).
My main take away from this thread is that there is agreement about the
dates and discussion about process.
Tom
On Sat, Oct 13, 2018 at 4:26 PM Antony Lee <anntzer.lee at gmail.com> wrote:
I have no problem with branching 3.1 early (we are already managing
backports into the very-long-lived 2.2.x branch and that doesn't seem to be
a problem at all). I'm not sure why you'd want to prevent feature merges
to master for a month. It's not the end of the world if 3.1 takes 45 days
or even 60 to be released instead of 30...
AntonyOn Fri, Oct 12, 2018 at 8:54 PM Nelle Varoquaux <nelle.varoquaux at gmail.com> > wrote:
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.
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.Cheers,
NOn Fri, 12 Oct 2018 at 10:33, Ryan May <rmay31 at gmail.com> wrote:
Nelle,
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.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.Ryan
On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux < >>> nelle.varoquaux at gmail.com> wrote:
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?Cheers,
NOn Wed, 10 Oct 2018 at 18:50, Thomas Caswell <tcaswell at gmail.com> >>>> wrote:
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.Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary
and a final release sometime in March?Tom
On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <pmhobson at gmail.com> >>>>> wrote:
Agree with Ryan.
On Wed, Oct 10, 2018 at 11:36 AM Ryan May <rmay31 at gmail.com> wrote:
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.Ryan
On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <tcaswell at gmail.com> >>>>>>> wrote:
Folks,
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.Thoughts?
Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page
--
Thomas Caswell
tcaswell at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181016/7c2bb06e/attachment.html>
If people have bandwidth and a mac, I think the highest priority thing left
for 3.0.1 is the bouncing rocket on OSX
Tom
On Tue, Oct 16, 2018 at 8:48 AM Thomas Caswell <tcaswell at gmail.com> wrote:
I am also not worried about forking early. Meeseeksdev makes it pretty
easy to manage backports. I am cautious about over-learning from the 2.0
release process. Mike and I drastically under-estimated the amount of work
that would be required to begin with and I ended up being the bottle neck
on a number of issues at the end.I think we are too distributed with too many volunteer devs to freeze
master for a few weeks (on the other hand, freezing master is definitely
how we do this on my day-job projects!).My main take away from this thread is that there is agreement about the
dates and discussion about process.Tom
On Sat, Oct 13, 2018 at 4:26 PM Antony Lee <anntzer.lee at gmail.com> wrote:
I have no problem with branching 3.1 early (we are already managing
backports into the very-long-lived 2.2.x branch and that doesn't seem to be
a problem at all). I'm not sure why you'd want to prevent feature merges
to master for a month. It's not the end of the world if 3.1 takes 45 days
or even 60 to be released instead of 30...
AntonyOn Fri, Oct 12, 2018 at 8:54 PM Nelle Varoquaux < >> nelle.varoquaux at gmail.com> wrote:
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.
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.Cheers,
NOn Fri, 12 Oct 2018 at 10:33, Ryan May <rmay31 at gmail.com> wrote:
Nelle,
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.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.Ryan
On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux < >>>> nelle.varoquaux at gmail.com> wrote:
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?Cheers,
NOn Wed, 10 Oct 2018 at 18:50, Thomas Caswell <tcaswell at gmail.com> >>>>> wrote:
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.Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary
and a final release sometime in March?Tom
On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <pmhobson at gmail.com> >>>>>> wrote:
Agree with Ryan.
On Wed, Oct 10, 2018 at 11:36 AM Ryan May <rmay31 at gmail.com> wrote:
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.Ryan
On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <tcaswell at gmail.com> >>>>>>>> wrote:
Folks,
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.Thoughts?
Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Ryan May_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page--
Thomas Caswell
tcaswell at gmail.com
--
Thomas Caswell
tcaswell at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181016/132050ba/attachment-0001.html>