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 <damon.mcdoug...@gmail.com
<mailto:damon.mcdoug...@gmail.com>> wrote:
> On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux
> <nelle.varoqu...@gmail.com <mailto:nelle.varoqu...@gmail.com>> wrote:
>>
>>
>> On 15 October 2012 06:10, Eric Firing <efir...@hawaii.edu
<mailto:efir...@hawaii.edu>> wrote:
>>>
>>> On 2012/10/14 12:44 PM, Damon McDougall wrote:
>>> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <efir...@hawaii.edu
<mailto:efir...@hawaii.edu>> 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
> Matplotlib-devel@lists.sourceforge.net
<mailto: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
