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

[Damon M. <dam...@gm...>]

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