strategy for 1.2.x, master, PEP8 changes

Development matplotlib-devel
1

All,

I think we are in a messy situation, and we need to reach some agreement as to how to proceed. This has been discussed a bit in this thread:

http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel

The name of that thread did not reflect the importance of the discussion it prompted, hence the present message.

To summarize my view:

1) We have a flood of PEP8 PRs based on master, many of which have been merged, some by myself--so I have no objection to this aspect of the situation, though I would have preferred a slower pace, a garden hose rather than a fire hose. I am happy to see continued merging of these PRs into master.

2) We are also trying to stabilize v1.2.x, getting in the last few bug fixes and doc updates, so we can get a release out, with a high probability that it will be solid.

3) The potential disagreement is over whether the PEP8 changes should be cherry-picked into v1.2.x, or simply left in master. I favor the latter course. First, because massive code churn shortly before a release seems unwise. Second, because I think we should stick to the strategy we started with, in which an effort is made to choose the most appropriate target for each PR, frequently merge the maintenance branch into master, and reserve cherry-picking for occasional corrections.

4) The PEP8 changes will cause some merge problems no matter what we do; but I think that they can be minimal and manageable if we leave PEP8 out of v1.2.x, and decide that once it is released, v1.2.x will be changed only if critical bugs are found, requiring a v1.2.1 release. This also assumes that we have only a few changes left to be made in v1.2.x before a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be in v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

Agreement? Disagreement? Discussion? Related aspects of strategy?

Eric

2

I'm happy with whatever is decided. I'd rather not have merge
conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
not cherry-pick them into 1.2.x.

If it is decided that we are to revert all the PEP8 changes in 1.2.x,
what should be done about PEP8 changes that were merged into master
before the v1.2.x branch was created?

···

On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efiring@...229...> wrote:

All,

I think we are in a messy situation, and we need to reach some agreement
as to how to proceed. This has been discussed a bit in this thread:

Thread: [matplotlib-devel] PEP8 github label | matplotlib

The name of that thread did not reflect the importance of the discussion
it prompted, hence the present message.

To summarize my view:

1) We have a flood of PEP8 PRs based on master, many of which have been
merged, some by myself--so I have no objection to this aspect of the
situation, though I would have preferred a slower pace, a garden hose
rather than a fire hose. I am happy to see continued merging of these
PRs into master.

2) We are also trying to stabilize v1.2.x, getting in the last few bug
fixes and doc updates, so we can get a release out, with a high
probability that it will be solid.

3) The potential disagreement is over whether the PEP8 changes should be
cherry-picked into v1.2.x, or simply left in master. I favor the latter
course. First, because massive code churn shortly before a release
seems unwise. Second, because I think we should stick to the strategy
we started with, in which an effort is made to choose the most
appropriate target for each PR, frequently merge the maintenance branch
into master, and reserve cherry-picking for occasional corrections.

4) The PEP8 changes will cause some merge problems no matter what we do;
but I think that they can be minimal and manageable if we leave PEP8 out
of v1.2.x, and decide that once it is released, v1.2.x will be changed
only if critical bugs are found, requiring a v1.2.1 release. This also
assumes that we have only a few changes left to be made in v1.2.x before
a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been
cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be in
v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

Agreement? Disagreement? Discussion? Related aspects of strategy?

Eric

--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

3

I'm not familiar with matplotlib's merge strategy, but I'd agree with
you that making those changes post-RC doesn't sound sensible. There's
always the chance of something getting broken, especially when diffs
get too big to review carefully.

Thomas

···

On 14 October 2012 21:22, Eric Firing <efiring@...229...> wrote:

3) The potential disagreement is over whether the PEP8 changes should be
cherry-picked into v1.2.x, or simply left in master. I favor the latter
course.

4

I didn't know there were any; but anything that far back should be left alone, because subsequent things are based on it, and it has been getting tested along the way during the rc cycle. My concern is with massive changes shortly before release, and about getting the release over and done with so we can move on.

Eric

···

On 2012/10/14 12:44 PM, Damon McDougall wrote:

On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efiring@...229...> wrote:

All,

I think we are in a messy situation, and we need to reach some agreement
as to how to proceed. This has been discussed a bit in this thread:

Thread: [matplotlib-devel] PEP8 github label | matplotlib

The name of that thread did not reflect the importance of the discussion
it prompted, hence the present message.

To summarize my view:

1) We have a flood of PEP8 PRs based on master, many of which have been
merged, some by myself--so I have no objection to this aspect of the
situation, though I would have preferred a slower pace, a garden hose
rather than a fire hose. I am happy to see continued merging of these
PRs into master.

2) We are also trying to stabilize v1.2.x, getting in the last few bug
fixes and doc updates, so we can get a release out, with a high
probability that it will be solid.

3) The potential disagreement is over whether the PEP8 changes should be
cherry-picked into v1.2.x, or simply left in master. I favor the latter
course. First, because massive code churn shortly before a release
seems unwise. Second, because I think we should stick to the strategy
we started with, in which an effort is made to choose the most
appropriate target for each PR, frequently merge the maintenance branch
into master, and reserve cherry-picking for occasional corrections.

4) The PEP8 changes will cause some merge problems no matter what we do;
but I think that they can be minimal and manageable if we leave PEP8 out
of v1.2.x, and decide that once it is released, v1.2.x will be changed
only if critical bugs are found, requiring a v1.2.1 release. This also
assumes that we have only a few changes left to be made in v1.2.x before
a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been
cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be in
v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

Agreement? Disagreement? Discussion? Related aspects of strategy?

Eric

I'm happy with whatever is decided. I'd rather not have merge
conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
not cherry-pick them into 1.2.x.

If it is decided that we are to revert all the PEP8 changes in 1.2.x,
what should be done about PEP8 changes that were merged into master
before the v1.2.x branch was created?

5

I'd agree with Eric on most of his points.

···

On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing <efiring@...229...> wrote:

If some of the PEP8 commits include genuine bug-fixes that need to be in
v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

I think it is not a good idea to have a PR that mixes a bug-fix with a
PEP8 fix that is not related with the bug.
Maybe we need to ask for separate PRs, one for PEP8 fix and one for bug-fixes.

Regards,

-JJ

6

I'd agree with Eric on most of his points.

If some of the PEP8 commits include genuine bug-fixes that need to be in
v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

I think it is not a good idea to have a PR that mixes a bug-fix with a
PEP8 fix that is not related with the bug.
Maybe we need to ask for separate PRs, one for PEP8 fix and one for bug-fixes.

I think that has been the case; certainly it has been the general intention. I put in the remark you quoted in case there might have been one or two small exceptions.

Eric

···

On 2012/10/14 4:49 PM, Jae-Joon Lee wrote:

On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing <efiring@...229...> wrote:

Regards,

-JJ

7

Damon,

As I said, I would not advocate trying to back out everything, and maybe not any of what is already in 1.2.x, or maybe just the most recent bunch. Anticipating that Mike D. might want to make a decision tomorrow (or today from your timezone), perhaps it would be helpful if you could make an approximate map of which PEP8 commits were cherry-picked to 1.2.x, and how recently? I have been trying to figure this out with qgit and git log with various options, but it makes my head spin.

Thanks.

Eric

···

On 2012/10/14 12:44 PM, Damon McDougall wrote:

On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efiring@...229...> wrote:

All,

I think we are in a messy situation, and we need to reach some agreement
as to how to proceed. This has been discussed a bit in this thread:

Thread: [matplotlib-devel] PEP8 github label | matplotlib

The name of that thread did not reflect the importance of the discussion
it prompted, hence the present message.

To summarize my view:

1) We have a flood of PEP8 PRs based on master, many of which have been
merged, some by myself--so I have no objection to this aspect of the
situation, though I would have preferred a slower pace, a garden hose
rather than a fire hose. I am happy to see continued merging of these
PRs into master.

2) We are also trying to stabilize v1.2.x, getting in the last few bug
fixes and doc updates, so we can get a release out, with a high
probability that it will be solid.

3) The potential disagreement is over whether the PEP8 changes should be
cherry-picked into v1.2.x, or simply left in master. I favor the latter
course. First, because massive code churn shortly before a release
seems unwise. Second, because I think we should stick to the strategy
we started with, in which an effort is made to choose the most
appropriate target for each PR, frequently merge the maintenance branch
into master, and reserve cherry-picking for occasional corrections.

4) The PEP8 changes will cause some merge problems no matter what we do;
but I think that they can be minimal and manageable if we leave PEP8 out
of v1.2.x, and decide that once it is released, v1.2.x will be changed
only if critical bugs are found, requiring a v1.2.1 release. This also
assumes that we have only a few changes left to be made in v1.2.x before
a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been
cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be in
v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

Agreement? Disagreement? Discussion? Related aspects of strategy?

Eric

I'm happy with whatever is decided. I'd rather not have merge
conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
not cherry-pick them into 1.2.x.

If it is decided that we are to revert all the PEP8 changes in 1.2.x,
what should be done about PEP8 changes that were merged into master
before the v1.2.x branch was created?

8

All,

I think we are in a messy situation, and we need to reach some agreement

as to how to proceed. This has been discussed a bit in this thread:

http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel

The name of that thread did not reflect the importance of the discussion

it prompted, hence the present message.

To summarize my view:

  1. We have a flood of PEP8 PRs based on master, many of which have been

merged, some by myself–so I have no objection to this aspect of the

situation, though I would have preferred a slower pace, a garden hose

rather than a fire hose. I am happy to see continued merging of these

PRs into master.

  1. We are also trying to stabilize v1.2.x, getting in the last few bug

fixes and doc updates, so we can get a release out, with a high

probability that it will be solid.

  1. The potential disagreement is over whether the PEP8 changes should be

cherry-picked into v1.2.x, or simply left in master. I favor the latter

course. First, because massive code churn shortly before a release

seems unwise. Second, because I think we should stick to the strategy

we started with, in which an effort is made to choose the most

appropriate target for each PR, frequently merge the maintenance branch

into master, and reserve cherry-picking for occasional corrections.

  1. The PEP8 changes will cause some merge problems no matter what we do;

but I think that they can be minimal and manageable if we leave PEP8 out

of v1.2.x, and decide that once it is released, v1.2.x will be changed

only if critical bugs are found, requiring a v1.2.1 release. This also

assumes that we have only a few changes left to be made in v1.2.x before

a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been

cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x

milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be in

v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

Agreement? Disagreement? Discussion? Related aspects of strategy?

Eric

I’m happy with whatever is decided. I’d rather not have merge

conflicts, but if PEP8 is seen as a high-risk merge then I’m happy to

not cherry-pick them into 1.2.x.

If it is decided that we are to revert all the PEP8 changes in 1.2.x,

what should be done about PEP8 changes that were merged into master

before the v1.2.x branch was created?

Damon,

As I said, I would not advocate trying to back out everything, and maybe

not any of what is already in 1.2.x, or maybe just the most recent

bunch. Anticipating that Mike D. might want to make a decision tomorrow

(or today from your timezone), perhaps it would be helpful if you could

make an approximate map of which PEP8 commits were cherry-picked to

1.2.x, and how recently? I have been trying to figure this out with

qgit and git log with various options, but it makes my head spin.

List of commits that were cherry-picked recently (names only, but I can do the commit id as well):

PEP8 fixes on blocking_input.py

PEP8 fixes on blocking_input (patch n°2)

PEP_ fixes on cbook.py

PEP8 fixes 2. => 2.0

PEP8 fixes on tight_bbox.py

PEP8 fixes on tight_layout.py

PEP8 fixes - break points and identation

PEP8 fixes on type1font.py

PEP8 fixes - small backslashes and breaks fixes

PEP8 fixes on transforms.py

FIX - travis-ci is failing

Fix typo in transforms.py

PEP8 fixes on scale.py

PEP8 fixes on legend.py

PEP8 fixes on ticker.py

PEP8 fixes on streamplot.py

PEP8 fixes on stackplot.py

PEP8 fixes on hatch.py

PEP8 fixes on table.py

Thanks,

N

···

On 15 October 2012 06:10, Eric Firing <efiring@…229…> wrote:

On 2012/10/14 12:44 PM, Damon McDougall wrote:

On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efiring@…229…> wrote:

Thanks.

Eric

Don’t let slow site performance ruin your business. Deploy New Relic APM

Deploy New Relic app performance management and know exactly

what is happening inside your Ruby, Python, PHP, Java, and .NET app

Try New Relic at no cost today and get our sweet Data Nerd shirt too!

http://p.sf.net/sfu/newrelic-dev2dev

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

9

I’d agree with Eric on most of his points.

If some of the PEP8 commits include genuine bug-fixes that need to be in

v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

I think it is not a good idea to have a PR that mixes a bug-fix with a

PEP8 fix that is not related with the bug.

Maybe we need to ask for separate PRs, one for PEP8 fix and one for bug-fixes.

I usually add a FIXME note in the code. I wouldn’t rush those bug fixes, as they often have been there for a long time and corresponds to code that just would not run (hence, code that isn’t tested).

···

On 15 October 2012 04:49, Jae-Joon Lee <lee.j.joon@…149…> wrote:

On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing <efiring@…229…> wrote:

Regards,

-JJ

Don’t let slow site performance ruin your business. Deploy New Relic APM

Deploy New Relic app performance management and know exactly

what is happening inside your Ruby, Python, PHP, Java, and .NET app

Try New Relic at no cost today and get our sweet Data Nerd shirt too!

http://p.sf.net/sfu/newrelic-dev2dev

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

10

Thanks Nelle.

Eric, is the list Nelle has provided what you were expecting?

···

On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux <nelle.varoquaux@...149...> wrote:

On 15 October 2012 06:10, Eric Firing <efiring@...229...> wrote:

On 2012/10/14 12:44 PM, Damon McDougall wrote:
> On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efiring@...229...> wrote:
>> All,
>>
>> I think we are in a messy situation, and we need to reach some
>> agreement
>> as to how to proceed. This has been discussed a bit in this thread:
>>
>>
>> Thread: [matplotlib-devel] PEP8 github label | matplotlib
>>
>> The name of that thread did not reflect the importance of the
>> discussion
>> it prompted, hence the present message.
>>
>> To summarize my view:
>>
>> 1) We have a flood of PEP8 PRs based on master, many of which have been
>> merged, some by myself--so I have no objection to this aspect of the
>> situation, though I would have preferred a slower pace, a garden hose
>> rather than a fire hose. I am happy to see continued merging of these
>> PRs into master.
>>
>> 2) We are also trying to stabilize v1.2.x, getting in the last few bug
>> fixes and doc updates, so we can get a release out, with a high
>> probability that it will be solid.
>>
>> 3) The potential disagreement is over whether the PEP8 changes should
>> be
>> cherry-picked into v1.2.x, or simply left in master. I favor the
>> latter
>> course. First, because massive code churn shortly before a release
>> seems unwise. Second, because I think we should stick to the strategy
>> we started with, in which an effort is made to choose the most
>> appropriate target for each PR, frequently merge the maintenance branch
>> into master, and reserve cherry-picking for occasional corrections.
>>
>> 4) The PEP8 changes will cause some merge problems no matter what we
>> do;
>> but I think that they can be minimal and manageable if we leave PEP8
>> out
>> of v1.2.x, and decide that once it is released, v1.2.x will be changed
>> only if critical bugs are found, requiring a v1.2.1 release. This also
>> assumes that we have only a few changes left to be made in v1.2.x
>> before
>> a final rc and a release.
>>
>> Therefore I recommend that the PEP8 changes that have already been
>> cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
>> milestone be removed from all PEP8 changes.
>>
>> If some of the PEP8 commits include genuine bug-fixes that need to be
>> in
>> v1.2.x, then these fixes should be made via PRs directly against
>> v1.2.x.
>>
>> Agreement? Disagreement? Discussion? Related aspects of strategy?
>>
>> Eric
>
> I'm happy with whatever is decided. I'd rather not have merge
> conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
> not cherry-pick them into 1.2.x.
>
> If it is decided that we are to revert all the PEP8 changes in 1.2.x,
> what should be done about PEP8 changes that were merged into master
> before the v1.2.x branch was created?
>

Damon,

As I said, I would not advocate trying to back out everything, and maybe
not any of what is already in 1.2.x, or maybe just the most recent
bunch. Anticipating that Mike D. might want to make a decision tomorrow
(or today from your timezone), perhaps it would be helpful if you could
make an approximate map of which PEP8 commits were cherry-picked to
1.2.x, and how recently? I have been trying to figure this out with
qgit and git log with various options, but it makes my head spin.

List of commits that were cherry-picked recently (names only, but I can do
the commit id as well):

PEP8 fixes on blocking_input.py
PEP8 fixes on blocking_input (patch n°2)
PEP_ fixes on cbook.py
PEP8 fixes 2. => 2.0
PEP8 fixes on tight_bbox.py
PEP8 fixes on tight_layout.py
PEP8 fixes - break points and identation
PEP8 fixes on type1font.py
PEP8 fixes - small backslashes and breaks fixes
PEP8 fixes on transforms.py
FIX - travis-ci is failing
Fix typo in transforms.py
PEP8 fixes on scale.py
PEP8 fixes on legend.py
PEP8 fixes on ticker.py
PEP8 fixes on streamplot.py
PEP8 fixes on stackplot.py
PEP8 fixes on hatch.py
PEP8 fixes on table.py

--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

11

Nelle, let me just take a moment to thank you for all the PEP8 work you have done. At first I was fine with these PRs being in v1.2.x, but now that some ports are being removed, perhaps it is best for these to all go into master.

Cheers!

Ben Root

···

On Monday, October 15, 2012, Nelle Varoquaux wrote:

On 15 October 2012 04:49, Jae-Joon Lee <lee.j.joon@…55…149…> wrote:

I’d agree with Eric on most of his points.

On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing <efiring@…229…> wrote:

If some of the PEP8 commits include genuine bug-fixes that need to be in

v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

I think it is not a good idea to have a PR that mixes a bug-fix with a

PEP8 fix that is not related with the bug.

Maybe we need to ask for separate PRs, one for PEP8 fix and one for bug-fixes.

I usually add a FIXME note in the code. I wouldn’t rush those bug fixes, as they often have been there for a long time and corresponds to code that just would not run (hence, code that isn’t tested).

12

Firstly, I think you are right to bring this up Eric, we should all agree what the best course is to take, and then all work together to get us there with the least amount of disruption possible.

if we leave PEP8 out of v1.2.x, and decide that once it is released, v1.2.x will be changed
only if critical bugs are found, requiring a v1.2.1 release

I agree. I think it is important here to be very clear about what constitutes a “critical bug”. In my opinion, releasing a v1.2.1 would be a very last resort and I would sooner see us move forward by fixing bugs in a new feature release (1.3). In order to do this we should have a schedule for our next release now, and ideally it shouldn’t be that far away (i.e. no longer than 8-9 months). Some of my reasons for this assertion include:

  1. We have an amazing community of people who help us build our release bundles - so the actual release deployment mechanisms are no longer a limiting factor
  2. We have a long period between identification of features, their implementation and then seeing those features available in the latest release to our users. I would love to see that time shorten to share some of the cool new features that are being developed with non-developers sooner so that we can get feedback and go through the development cycle quicker.
  3. Currently making a release is a massive task which takes many developers out of actually being able to focus on new features or bugfixes. Having a quicker release cycle should mean we have fewer large changes per release and reduce the need we currently have to squeeze as much as we can into the next release - ultimately I think it will mean that we need to expend fewer developer hours focused on release management and last minute code reviewing.
    This is not intended to be a criticism of our current system, simply an observation that I think could help us to be more responsive and agile in the future. If anybody wants to share their experiences with other development methodologies I would love to hear about them (I guess if it is not strictly related to this thread, then perhaps we should start up a new conversation on the mailing list).

In short, provided we can agree a future matplotlib version schedule, I agree with Eric. In terms of reverting the already cherry picked commits, I am less sure. My heart is telling me to draw a line in the sand, accept what is on the v1.2.x branch currently, and accept the suggested approach for all future commits.

Finally, I agree with Ben. This is not a criticism of Nelle’s PEP8 pull requests, or of Damon and other’s hard work in reviewing and merging them, it is simply that we should agree the best course to get the best possible release of v1.2.0 without dragging it out long beyond our original schedule.

Cheers,

Phil

···

On 15 October 2012 09:08, Damon McDougall <damon.mcdougall@…149…> wrote:

On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux > <nelle.varoquaux@…322…9…> wrote:

On 15 October 2012 06:10, Eric Firing <efiring@…1100…> wrote:

On 2012/10/14 12:44 PM, Damon McDougall wrote:

On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efiring@…229…> wrote:

All,

I think we are in a messy situation, and we need to reach some
agreement
as to how to proceed. This has been discussed a bit in this thread:

http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel

The name of that thread did not reflect the importance of the
discussion
it prompted, hence the present message.

To summarize my view:

  1. We have a flood of PEP8 PRs based on master, many of which have been
    merged, some by myself–so I have no objection to this aspect of the

situation, though I would have preferred a slower pace, a garden hose
rather than a fire hose. I am happy to see continued merging of these
PRs into master.

  1. We are also trying to stabilize v1.2.x, getting in the last few bug
    fixes and doc updates, so we can get a release out, with a high
    probability that it will be solid.
  1. The potential disagreement is over whether the PEP8 changes should
    be
    cherry-picked into v1.2.x, or simply left in master. I favor the

latter
course. First, because massive code churn shortly before a release
seems unwise. Second, because I think we should stick to the strategy

we started with, in which an effort is made to choose the most
appropriate target for each PR, frequently merge the maintenance branch
into master, and reserve cherry-picking for occasional corrections.

  1. The PEP8 changes will cause some merge problems no matter what we
    do;
    but I think that they can be minimal and manageable if we leave PEP8

out
of v1.2.x, and decide that once it is released, v1.2.x will be changed
only if critical bugs are found, requiring a v1.2.1 release. This also

assumes that we have only a few changes left to be made in v1.2.x
before
a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been

cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be

in
v1.2.x, then these fixes should be made via PRs directly against
v1.2.x.

Agreement? Disagreement? Discussion? Related aspects of strategy?

Eric

I’m happy with whatever is decided. I’d rather not have merge
conflicts, but if PEP8 is seen as a high-risk merge then I’m happy to

not cherry-pick them into 1.2.x.

If it is decided that we are to revert all the PEP8 changes in 1.2.x,
what should be done about PEP8 changes that were merged into master

before the v1.2.x branch was created?

Damon,

As I said, I would not advocate trying to back out everything, and maybe

not any of what is already in 1.2.x, or maybe just the most recent
bunch. Anticipating that Mike D. might want to make a decision tomorrow
(or today from your timezone), perhaps it would be helpful if you could

make an approximate map of which PEP8 commits were cherry-picked to
1.2.x, and how recently? I have been trying to figure this out with
qgit and git log with various options, but it makes my head spin.

List of commits that were cherry-picked recently (names only, but I can do
the commit id as well):

PEP8 fixes on blocking_input.py
PEP8 fixes on blocking_input (patch n°2)

PEP_ fixes on cbook.py
PEP8 fixes 2. => 2.0
PEP8 fixes on tight_bbox.py
PEP8 fixes on tight_layout.py
PEP8 fixes - break points and identation
PEP8 fixes on type1font.py

PEP8 fixes - small backslashes and breaks fixes
PEP8 fixes on transforms.py
FIX - travis-ci is failing
Fix typo in transforms.py
PEP8 fixes on scale.py
PEP8 fixes on legend.py

PEP8 fixes on ticker.py
PEP8 fixes on streamplot.py
PEP8 fixes on stackplot.py
PEP8 fixes on hatch.py
PEP8 fixes on table.py

Thanks Nelle.

Eric, is the list Nelle has provided what you were expecting?

–
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute

University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Don’t let slow site performance ruin your business. Deploy New Relic APM

Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!

http://p.sf.net/sfu/newrelic-dev2dev

Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

13

Sorry to be jumping in on this late -- I didn't have a chance to catch up with this over the weekend.

I think I generally side with Eric here -- the rc candidate cycle is intended to be quite conservative. Nelle's pull requests are very welcome improvements, but they are also quite large and I am concerned about breakage slipping through the cracks. To the extent that Nelle is finding undefined variable bugs etc. with her tool, I think we should probably try and fix those -- I know we've been doing that already and that's great.

I think we should take the 1.2.x milestone off of all of the PEP8 changes and keep all of them on master going forward. Yes, the merging may be difficult while we are still in maintaining 1.2.x, but I think that's trivial compared to all of the additional testing and push back of the 1.2.0 release that this is currently causing.

As for backing out things that were already cherry-picked -- that's a tough call. I don't want to exacerbate the situation by causing further risk. Maybe we just back out everything since the rc2?

Mike

···

On 10/15/2012 12:10 AM, Eric Firing wrote:

On 2012/10/14 12:44 PM, Damon McDougall wrote:

On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efiring@...229...> wrote:

All,

I think we are in a messy situation, and we need to reach some agreement
as to how to proceed. This has been discussed a bit in this thread:

Thread: [matplotlib-devel] PEP8 github label | matplotlib

The name of that thread did not reflect the importance of the discussion
it prompted, hence the present message.

To summarize my view:

1) We have a flood of PEP8 PRs based on master, many of which have been
merged, some by myself--so I have no objection to this aspect of the
situation, though I would have preferred a slower pace, a garden hose
rather than a fire hose. I am happy to see continued merging of these
PRs into master.

2) We are also trying to stabilize v1.2.x, getting in the last few bug
fixes and doc updates, so we can get a release out, with a high
probability that it will be solid.

3) The potential disagreement is over whether the PEP8 changes should be
cherry-picked into v1.2.x, or simply left in master. I favor the latter
course. First, because massive code churn shortly before a release
seems unwise. Second, because I think we should stick to the strategy
we started with, in which an effort is made to choose the most
appropriate target for each PR, frequently merge the maintenance branch
into master, and reserve cherry-picking for occasional corrections.

4) The PEP8 changes will cause some merge problems no matter what we do;
but I think that they can be minimal and manageable if we leave PEP8 out
of v1.2.x, and decide that once it is released, v1.2.x will be changed
only if critical bugs are found, requiring a v1.2.1 release. This also
assumes that we have only a few changes left to be made in v1.2.x before
a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been
cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be in
v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

Agreement? Disagreement? Discussion? Related aspects of strategy?

Eric

I'm happy with whatever is decided. I'd rather not have merge
conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
not cherry-pick them into 1.2.x.

If it is decided that we are to revert all the PEP8 changes in 1.2.x,
what should be done about PEP8 changes that were merged into master
before the v1.2.x branch was created?

Damon,

As I said, I would not advocate trying to back out everything, and maybe
not any of what is already in 1.2.x, or maybe just the most recent
bunch. Anticipating that Mike D. might want to make a decision tomorrow
(or today from your timezone), perhaps it would be helpful if you could
make an approximate map of which PEP8 commits were cherry-picked to
1.2.x, and how recently? I have been trying to figure this out with
qgit and git log with various options, but it makes my head spin.

Thanks.

Eric

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

14

I think a perennial problem has simply been keeping up with the
firehose of bugs, and we’ve been doing a lot of very impressive
catch-up during this release cycle.
I’m not sure that more frequent releases is necessarily the answer.
The amount of work doesn’t decrease – it’s just becomes less
“bursty”.
We also have the (not unique to us problem) that a key platform for
users (Windows) is not well-represented in the set of developers,
and the release candidates are always helpful for ferretting out
those bugs that don’t get discovered in the normal course of things.
Mike

···

On 10/15/2012 08:11 AM, Phil Elson
wrote:

  Firstly, I think you are right to bring this up Eric, we should

all agree what the best course is to take, and then all work
together to get us there with the least amount of disruption
possible.

  > if we leave PEP8 out of v1.2.x, and decide that once it is

released, v1.2.x will be changed

  > only if critical bugs are found, requiring a v1.2.1 release



  I agree. I think it is important here to be very clear about what

constitutes a “critical bug”. In my opinion, releasing a v1.2.1
would be a very last resort and I would sooner see us move forward
by fixing bugs in a new feature release (1.3). In order to do this
we should have a schedule for our next release now, and ideally
it shouldn’t be that far away (i.e. no longer than 8-9 months).
Some of my reasons for this assertion include:

  1.       We have an amazing community of people who help us build our

release bundles - so the actual release deployment mechanisms
are no longer a limiting factor

  1.       We have a long period between identification of features,

their implementation and then seeing those features available
in the latest release to our users. I would love to see that
time shorten to share some of the cool new features that are
being developed with non-developers sooner so that we can get
feedback and go through the development cycle quicker.

  1.       Currently making a release is a massive task which takes

many developers out of actually being able to focus on new
features or bugfixes. Having a quicker release cycle should
mean we have fewer large changes per release and reduce the
need we currently have to squeeze as much as we can into the
next release - ultimately I think it will mean that we need to
expend fewer developer hours focused on release management and
last minute code reviewing.

    This is not intended to be a criticism of our current system,

simply an observation that I think could help us to be more
responsive and agile in the future. If anybody wants to share
their experiences with other development methodologies I would
love to hear about them (I guess if it is not strictly related
to this thread, then perhaps we should start up a new
conversation on the mailing list).

    In short, provided we can agree a future matplotlib version

schedule, I agree with Eric. In terms of reverting the already
cherry picked commits, I am less sure. My heart is telling me to
draw a line in the sand, accept what is on the v1.2.x branch
currently, and accept the suggested approach for all future
commits.

    Finally, I agree with Ben. This is not a criticism of Nelle's

PEP8 pull requests, or of Damon and other’s hard work in
reviewing and merging them, it is simply that we should agree
the best course to get the best possible release of v1.2.0
without dragging it out long beyond our original schedule.

Cheers,

Phil

  On 15 October 2012 09:08, Damon McDougall <damon.mcdougall@...149...      >

wrote:

  > On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux

  > <nelle.varoquaux@...149...      >

wrote:

  >>

  >>

  >> On 15 October 2012 06:10, Eric Firing <efiring@...229...      >

wrote:

  >>>

  >>> On 2012/10/14 12:44 PM, Damon McDougall wrote:

  >>> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing

<efiring@…229… >
wrote:

  >>> >> All,

  >>> >>

  >>> >> I think we are in a messy situation, and we

need to reach some

  >>> >> agreement

  >>> >> as to how to proceed.  This has been

discussed a bit in this thread:

  >>> >>

  >>> >>

  >>> >> [http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel](http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel)

  >>> >>

  >>> >> The name of that thread did not reflect the

importance of the

  >>> >> discussion

  >>> >> it prompted, hence the present message.

  >>> >>

  >>> >> To summarize my view:

  >>> >>

  >>> >> 1) We have a flood of PEP8 PRs based on

master, many of which have been

  >>> >> merged, some by myself--so I have no

objection to this aspect of the

  >>> >> situation, though I would have preferred a

slower pace, a garden hose

  >>> >> rather than a fire hose.  I am happy to see

continued merging of these

  >>> >> PRs into master.

  >>> >>

  >>> >> 2) We are also trying to stabilize v1.2.x,

getting in the last few bug

  >>> >> fixes and doc updates, so we can get a

release out, with a high

  >>> >> probability that it will be solid.

  >>> >>

  >>> >> 3) The potential disagreement is over

whether the PEP8 changes should

  >>> >> be

  >>> >> cherry-picked into v1.2.x, or simply left in

master. I favor the

  >>> >> latter

  >>> >> course.  First, because massive code churn

shortly before a release

  >>> >> seems unwise.  Second, because I think we

should stick to the strategy

  >>> >> we started with, in which an effort is made

to choose the most

  >>> >> appropriate target for each PR, frequently

merge the maintenance branch

  >>> >> into master, and reserve cherry-picking for

occasional corrections.

  >>> >>

  >>> >> 4) The PEP8 changes will cause some merge

problems no matter what we

  >>> >> do;

  >>> >> but I think that they can be minimal and

manageable if we leave PEP8

  >>> >> out

  >>> >> of v1.2.x, and decide that once it is

released, v1.2.x will be changed

  >>> >> only if critical bugs are found, requiring a

v1.2.1 release. This also

  >>> >> assumes that we have only a few changes left

to be made in v1.2.x

  >>> >> before

  >>> >> a final rc and a release.

  >>> >>

  >>> >> Therefore I recommend that the PEP8 changes

that have already been

  >>> >> cherry-picked into v1.2.x be removed from

v1.2.x, and that the v1.2.x

  >>> >> milestone be removed from all PEP8 changes.

  >>> >>

  >>> >> If some of the PEP8 commits include genuine

bug-fixes that need to be

  >>> >> in

  >>> >> v1.2.x, then these fixes should be made via

PRs directly against

  >>> >> v1.2.x.

  >>> >>

  >>> >> Agreement?  Disagreement?  Discussion?

Related aspects of strategy?

  >>> >>

  >>> >> Eric

  >>> >

  >>> > I'm happy with whatever is decided. I'd rather

not have merge

  >>> > conflicts, but if PEP8 is seen as a high-risk

merge then I’m happy to

  >>> > not cherry-pick them into 1.2.x.

  >>> >

  >>> > If it is decided that we are to revert all the

PEP8 changes in 1.2.x,

  >>> > what should be done about PEP8 changes that were

merged into master

  >>> > before the v1.2.x branch was created?

  >>> >

  >>>

  >>> Damon,

  >>>

  >>> As I said, I would not advocate trying to back out

everything, and maybe

  >>> not any of what is already in 1.2.x, or maybe just

the most recent

  >>> bunch.  Anticipating that Mike D. might want to make

a decision tomorrow

  >>> (or today from your timezone), perhaps it would be

helpful if you could

  >>> make an approximate map of which PEP8 commits were

cherry-picked to

  >>> 1.2.x, and how recently?  I have been trying to

figure this out with

  >>> qgit and git log with various options, but it makes

my head spin.

  >>

  >>

  >> List of commits that were cherry-picked recently (names

only, but I can do

  >> the commit id as well):

  >>

  >> PEP8 fixes on blocking_input.py

  >> PEP8 fixes on blocking_input (patch n°2)

  >> PEP_ fixes on cbook.py

  >> PEP8 fixes 2. => 2.0

  >> PEP8 fixes on tight_bbox.py

  >> PEP8 fixes on tight_layout.py

  >> PEP8 fixes - break points and identation

  >> PEP8 fixes on type1font.py

  >> PEP8 fixes - small backslashes and breaks fixes

  >> PEP8 fixes on transforms.py

  >> FIX - travis-ci is failing

  >> Fix typo in transforms.py

  >> PEP8 fixes on scale.py

  >> PEP8 fixes on legend.py

  >> PEP8 fixes on ticker.py

  >> PEP8 fixes on streamplot.py

  >> PEP8 fixes on stackplot.py

  >> PEP8 fixes on hatch.py

  >> PEP8 fixes on table.py

  >

  > Thanks Nelle.

  >

  > Eric, is the list Nelle has provided what you were expecting?

  >

  > --

  > Damon McDougall

  > [http://www.damon-is-a-geek.com](http://www.damon-is-a-geek.com)

  > B2.39

  > Mathematics Institute

  > University of Warwick

  > Coventry

  > West Midlands

  > CV4 7AL

  > United Kingdom

  >

  >

  > Don't let slow site performance ruin your business. Deploy

New Relic APM

  > Deploy New Relic app performance management and know exactly

  > what is happening inside your Ruby, Python, PHP, Java, and

.NET app

  > Try New Relic at no cost today and get our sweet Data Nerd

shirt too!

  > [http://p.sf.net/sfu/newrelic-dev2dev](http://p.sf.net/sfu/newrelic-dev2dev)

  > _______________________________________________

  > Matplotlib-devel mailing list

  > Matplotlib-devel@lists.sourceforge.net

  > [https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!

_______________________________________________
Matplotlib-devel mailing list

http://p.sf.net/sfu/newrelic-dev2devMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel

15

Sorry to be jumping in on this late -- I didn't have a chance to catch
up with this over the weekend.

I think I generally side with Eric here -- the rc candidate cycle is
intended to be quite conservative. Nelle's pull requests are very
welcome improvements, but they are also quite large and I am concerned
about breakage slipping through the cracks. To the extent that Nelle is
finding undefined variable bugs etc. with her tool, I think we should
probably try and fix those -- I know we've been doing that already and
that's great.

I think we should take the 1.2.x milestone off of all of the PEP8
changes and keep all of them on master going forward. Yes, the merging
may be difficult while we are still in maintaining 1.2.x, but I think
that's trivial compared to all of the additional testing and push back
of the 1.2.0 release that this is currently causing.

As for backing out things that were already cherry-picked -- that's a
tough call. I don't want to exacerbate the situation by causing further
risk. Maybe we just back out everything since the rc2?

It looks like that would itself cause a huge amount of additional churn, and more risk than leaving things as they are. At this point I suggest leaving everything in that is presently in, try to get in the last few bug fixes and tweaks, tag an rc3, and then target a release date, somewhere in in the 2-4 weeks hence range. In the meantime, PEP8 PRs can be completed on master, after which feature enhancements can proceed on master.

Eric

···

On 2012/10/15 5:50 AM, Michael Droettboom wrote:

Mike

On 10/15/2012 12:10 AM, Eric Firing wrote:

On 2012/10/14 12:44 PM, Damon McDougall wrote:

On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efiring@...229...> wrote:

All,

I think we are in a messy situation, and we need to reach some agreement
as to how to proceed. This has been discussed a bit in this thread:

Thread: [matplotlib-devel] PEP8 github label | matplotlib

The name of that thread did not reflect the importance of the discussion
it prompted, hence the present message.

To summarize my view:

1) We have a flood of PEP8 PRs based on master, many of which have been
merged, some by myself--so I have no objection to this aspect of the
situation, though I would have preferred a slower pace, a garden hose
rather than a fire hose. I am happy to see continued merging of these
PRs into master.

2) We are also trying to stabilize v1.2.x, getting in the last few bug
fixes and doc updates, so we can get a release out, with a high
probability that it will be solid.

3) The potential disagreement is over whether the PEP8 changes should be
cherry-picked into v1.2.x, or simply left in master. I favor the latter
course. First, because massive code churn shortly before a release
seems unwise. Second, because I think we should stick to the strategy
we started with, in which an effort is made to choose the most
appropriate target for each PR, frequently merge the maintenance branch
into master, and reserve cherry-picking for occasional corrections.

4) The PEP8 changes will cause some merge problems no matter what we do;
but I think that they can be minimal and manageable if we leave PEP8 out
of v1.2.x, and decide that once it is released, v1.2.x will be changed
only if critical bugs are found, requiring a v1.2.1 release. This also
assumes that we have only a few changes left to be made in v1.2.x before
a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been
cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be in
v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

Agreement? Disagreement? Discussion? Related aspects of strategy?

Eric

I'm happy with whatever is decided. I'd rather not have merge
conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
not cherry-pick them into 1.2.x.

If it is decided that we are to revert all the PEP8 changes in 1.2.x,
what should be done about PEP8 changes that were merged into master
before the v1.2.x branch was created?

Damon,

As I said, I would not advocate trying to back out everything, and maybe
not any of what is already in 1.2.x, or maybe just the most recent
bunch. Anticipating that Mike D. might want to make a decision tomorrow
(or today from your timezone), perhaps it would be helpful if you could
make an approximate map of which PEP8 commits were cherry-picked to
1.2.x, and how recently? I have been trying to figure this out with
qgit and git log with various options, but it makes my head spin.

Thanks.

Eric

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

16

Sorry to be jumping in on this late -- I didn't have a chance to catch
up with this over the weekend.

I think I generally side with Eric here -- the rc candidate cycle is
intended to be quite conservative. Nelle's pull requests are very
welcome improvements, but they are also quite large and I am concerned
about breakage slipping through the cracks. To the extent that Nelle is
finding undefined variable bugs etc. with her tool, I think we should
probably try and fix those -- I know we've been doing that already and
that's great.

I think we should take the 1.2.x milestone off of all of the PEP8
changes and keep all of them on master going forward. Yes, the merging
may be difficult while we are still in maintaining 1.2.x, but I think
that's trivial compared to all of the additional testing and push back
of the 1.2.0 release that this is currently causing.

As for backing out things that were already cherry-picked -- that's a
tough call. I don't want to exacerbate the situation by causing further
risk. Maybe we just back out everything since the rc2?

It looks like that would itself cause a huge amount of additional churn,
and more risk than leaving things as they are. At this point I suggest
leaving everything in that is presently in, try to get in the last few
bug fixes and tweaks, tag an rc3, and then target a release date,
somewhere in in the 2-4 weeks hence range. In the meantime, PEP8 PRs
can be completed on master, after which feature enhancements can proceed
on master.

Yeah -- having just looked back at all of the cherry-picks at issue, that's where I've come down as well. Let's leave them in, but not put any further PEP8-only fixes on 1.2.x. I'll remove the 1.2.x issue labels on the few PRs in progress.

I also think it's not the end of the world if additional feature enhancements go on in master in the meantime. Any merge conflicts with the PEP8 work will be noted by git and we can address them as they come.

Any strong objections to this?

Mike

···

On 10/15/2012 12:52 PM, Eric Firing wrote:

On 2012/10/15 5:50 AM, Michael Droettboom wrote:

Eric

Mike

On 10/15/2012 12:10 AM, Eric Firing wrote:

On 2012/10/14 12:44 PM, Damon McDougall wrote:

On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efiring@...229...> wrote:

All,

I think we are in a messy situation, and we need to reach some agreement
as to how to proceed. This has been discussed a bit in this thread:

Thread: [matplotlib-devel] PEP8 github label | matplotlib

The name of that thread did not reflect the importance of the discussion
it prompted, hence the present message.

To summarize my view:

1) We have a flood of PEP8 PRs based on master, many of which have been
merged, some by myself--so I have no objection to this aspect of the
situation, though I would have preferred a slower pace, a garden hose
rather than a fire hose. I am happy to see continued merging of these
PRs into master.

2) We are also trying to stabilize v1.2.x, getting in the last few bug
fixes and doc updates, so we can get a release out, with a high
probability that it will be solid.

3) The potential disagreement is over whether the PEP8 changes should be
cherry-picked into v1.2.x, or simply left in master. I favor the latter
course. First, because massive code churn shortly before a release
seems unwise. Second, because I think we should stick to the strategy
we started with, in which an effort is made to choose the most
appropriate target for each PR, frequently merge the maintenance branch
into master, and reserve cherry-picking for occasional corrections.

4) The PEP8 changes will cause some merge problems no matter what we do;
but I think that they can be minimal and manageable if we leave PEP8 out
of v1.2.x, and decide that once it is released, v1.2.x will be changed
only if critical bugs are found, requiring a v1.2.1 release. This also
assumes that we have only a few changes left to be made in v1.2.x before
a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been
cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be in
v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

Agreement? Disagreement? Discussion? Related aspects of strategy?

Eric

I'm happy with whatever is decided. I'd rather not have merge
conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
not cherry-pick them into 1.2.x.

If it is decided that we are to revert all the PEP8 changes in 1.2.x,
what should be done about PEP8 changes that were merged into master
before the v1.2.x branch was created?

Damon,

As I said, I would not advocate trying to back out everything, and maybe
not any of what is already in 1.2.x, or maybe just the most recent
bunch. Anticipating that Mike D. might want to make a decision tomorrow
(or today from your timezone), perhaps it would be helpful if you could
make an approximate map of which PEP8 commits were cherry-picked to
1.2.x, and how recently? I have been trying to figure this out with
qgit and git log with various options, but it makes my head spin.

Thanks.

Eric

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

17

In the meantime, PEP8 PRs can be completed on master, after which feature enhancements can proceed on master.

I think it would be helpful to hold fire on the PEP8 changes until we have our rc3 and have merged it back onto master for (hopefully) the last time. That way, we wont have to deal with the conflicts that are inevitable when merging v1.2.x back to master.

Any merge conflicts with the PEP8 work will be noted by git and we can address them as they come.

That is another approach which will work, assuming the master is fairly up-to-date with v1.2.x now.

Any strong objections to this?

Nope. Sounds like a good plan.

In short, provided we can agree a future matplotlib version schedule, I agree with Eric.

Mike, Ben, Eric & others, there is a new thread relating to scheduling of releases, it is my opinion that it would be really beneficial to have a planned release date for v1.3 (and maybe even v1.4/v2.0) that we all agree on.

Phil

···

On 15 October 2012 17:59, Michael Droettboom <mdroe@…31…> wrote:

On 10/15/2012 12:52 PM, Eric Firing wrote:

On 2012/10/15 5:50 AM, Michael Droettboom wrote:

Sorry to be jumping in on this late – I didn’t have a chance to catch

up with this over the weekend.

I think I generally side with Eric here – the rc candidate cycle is

intended to be quite conservative. Nelle’s pull requests are very

welcome improvements, but they are also quite large and I am concerned

about breakage slipping through the cracks. To the extent that Nelle is

finding undefined variable bugs etc. with her tool, I think we should

probably try and fix those – I know we’ve been doing that already and

that’s great.

I think we should take the 1.2.x milestone off of all of the PEP8

changes and keep all of them on master going forward. Yes, the merging

may be difficult while we are still in maintaining 1.2.x, but I think

that’s trivial compared to all of the additional testing and push back

of the 1.2.0 release that this is currently causing.

As for backing out things that were already cherry-picked – that’s a

tough call. I don’t want to exacerbate the situation by causing further

risk. Maybe we just back out everything since the rc2?

It looks like that would itself cause a huge amount of additional churn,

and more risk than leaving things as they are. At this point I suggest

leaving everything in that is presently in, try to get in the last few

bug fixes and tweaks, tag an rc3, and then target a release date,

somewhere in in the 2-4 weeks hence range. In the meantime, PEP8 PRs

can be completed on master, after which feature enhancements can proceed

on master.

Yeah – having just looked back at all of the cherry-picks at issue,

that’s where I’ve come down as well. Let’s leave them in, but not put

any further PEP8-only fixes on 1.2.x. I’ll remove the 1.2.x issue

labels on the few PRs in progress.

I also think it’s not the end of the world if additional feature

enhancements go on in master in the meantime. Any merge conflicts with

the PEP8 work will be noted by git and we can address them as they come.

Any strong objections to this?

Mike

Eric

Mike

On 10/15/2012 12:10 AM, Eric Firing wrote:

On 2012/10/14 12:44 PM, Damon McDougall wrote:

On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efiring@…229…> wrote:

All,

I think we are in a messy situation, and we need to reach some agreement

as to how to proceed. This has been discussed a bit in this thread:

http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel

The name of that thread did not reflect the importance of the discussion

it prompted, hence the present message.

To summarize my view:

  1. We have a flood of PEP8 PRs based on master, many of which have been

merged, some by myself–so I have no objection to this aspect of the

situation, though I would have preferred a slower pace, a garden hose

rather than a fire hose. I am happy to see continued merging of these

PRs into master.

  1. We are also trying to stabilize v1.2.x, getting in the last few bug

fixes and doc updates, so we can get a release out, with a high

probability that it will be solid.

  1. The potential disagreement is over whether the PEP8 changes should be

cherry-picked into v1.2.x, or simply left in master. I favor the latter

course. First, because massive code churn shortly before a release

seems unwise. Second, because I think we should stick to the strategy

we started with, in which an effort is made to choose the most

appropriate target for each PR, frequently merge the maintenance branch

into master, and reserve cherry-picking for occasional corrections.

  1. The PEP8 changes will cause some merge problems no matter what we do;

but I think that they can be minimal and manageable if we leave PEP8 out

of v1.2.x, and decide that once it is released, v1.2.x will be changed

only if critical bugs are found, requiring a v1.2.1 release. This also

assumes that we have only a few changes left to be made in v1.2.x before

a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been

cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x

milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be in

v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

Agreement? Disagreement? Discussion? Related aspects of strategy?

Eric

I’m happy with whatever is decided. I’d rather not have merge

conflicts, but if PEP8 is seen as a high-risk merge then I’m happy to

not cherry-pick them into 1.2.x.

If it is decided that we are to revert all the PEP8 changes in 1.2.x,

what should be done about PEP8 changes that were merged into master

before the v1.2.x branch was created?

Damon,

As I said, I would not advocate trying to back out everything, and maybe

not any of what is already in 1.2.x, or maybe just the most recent

bunch. Anticipating that Mike D. might want to make a decision tomorrow

(or today from your timezone), perhaps it would be helpful if you could

make an approximate map of which PEP8 commits were cherry-picked to

1.2.x, and how recently? I have been trying to figure this out with

qgit and git log with various options, but it makes my head spin.

Thanks.

Eric

Don’t let slow site performance ruin your business. Deploy New Relic APM

Deploy New Relic app performance management and know exactly

what is happening inside your Ruby, Python, PHP, Java, and .NET app

Try New Relic at no cost today and get our sweet Data Nerd shirt too!

http://p.sf.net/sfu/newrelic-dev2dev

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Don’t let slow site performance ruin your business. Deploy New Relic APM

Deploy New Relic app performance management and know exactly

what is happening inside your Ruby, Python, PHP, Java, and .NET app

Try New Relic at no cost today and get our sweet Data Nerd shirt too!

http://p.sf.net/sfu/newrelic-dev2dev

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Don’t let slow site performance ruin your business. Deploy New Relic APM

Deploy New Relic app performance management and know exactly

what is happening inside your Ruby, Python, PHP, Java, and .NET app

Try New Relic at no cost today and get our sweet Data Nerd shirt too!

http://p.sf.net/sfu/newrelic-dev2dev

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Don’t let slow site performance ruin your business. Deploy New Relic APM

Deploy New Relic app performance management and know exactly

what is happening inside your Ruby, Python, PHP, Java, and .NET app

Try New Relic at no cost today and get our sweet Data Nerd shirt too!

http://p.sf.net/sfu/newrelic-dev2dev

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel