Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-15 Thread Nelle Varoquaux 
On 15 October 2012 06:10, Eric Firing  wrote:

> On 2012/10/14 12:44 PM, Damon McDougall wrote:
> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing  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.
> >>
> >> 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,
N


>
> 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
> [email protected]
> 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

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-15 Thread Nelle Varoquaux 
On 15 October 2012 04:49, Jae-Joon Lee  wrote:

> I'd agree with Eric on most of his points.
>
> On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing  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).


>
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-15 Thread Damon McDougall 
On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux
 wrote:
>
>
> On 15 October 2012 06:10, Eric Firing  wrote:
>>
>> On 2012/10/14 12:44 PM, Damon McDougall wrote:
>> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing  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.
>> >>
>> >> 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
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

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-15 Thread Benjamin Root 
On Monday, October 15, 2012, Nelle Varoquaux wrote:

>
>
> On 15 October 2012 04:49, Jae-Joon Lee 
> 
> > wrote:
>
>> I'd agree with Eric on most of his points.
>>
>> On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing 
>> >
>> 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).
>
>

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
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-15 Thread Phil Elson 
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  wrote:
> On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux
>  wrote:
>>
>>
>> On 15 October 2012 06:10, Eric Firing  wrote:
>>>
>>> On 2012/10/14 12:44 PM, Damon McDougall wrote:
>>> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing 
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.
>>> >>
>>> >> 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

[matplotlib-devel] 1.3+ Release schedule (was: strategy for 1.2.x, master, PEP8 changes)

2012-10-15 Thread Todd 
On Mon, Oct 15, 2012 at 2:11 PM, Phil Elson  wrote:
>> 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:
>
> 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
> 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.
> 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.
>
>  [snip]
>
> Phil

Why 8 to 9 months? This still seems like a very long time for a
project of this size. Much larger and more complicated projects
(gnome, KDE, Ubuntu) manage a 6 month release cycle, and for projects
this size I follow 2 to 3 months seems more typical. It's there a
reason the release cycle needs to be so long?

With a few month release schedule you can probably manage just 2 betas
and an rc, judging by other projects.

Also, have you considered a "master is always stable" approach, where
branches are only merged when they are complete? This could make
arbitrary release points much easier.

So basically, rather than waiting until you have a lot done for a new
release, you could have an approach more like Firefox now where each
release just had a couple new features, or maybe even just one big
feature.  Then a very quick beta cycle, and bugfix releases when
needed, but with that quick of a release cycle bugfix releases should
not be as important as they are now.  Other features would be worked
on in parallel in their own branch, ignoring the release entirely.

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-15 Thread Michael Droettboom 
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  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.
>>>
>>> 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
> [email protected]
> http

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-15 Thread Michael Droettboom 

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
 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.



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

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 > wrote:

> On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux
> mailto:[email protected]>> wrote:
>>
>>
>> On 15 October 2012 06:10, Eric Firing > wrote:

>>>
>>> On 2012/10/14 12:44 PM, Damon McDougall wrote:
>>> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing > 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.
>>> >>
>>> >> 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) Th

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-15 Thread Eric Firing 
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.

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  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.

 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 v

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-15 Thread Michael Droettboom 
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  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.
>
> 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