Menu
▾
▴
Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes
|
From: Michael D. <md...@st...> - 2012-10-15 16:10:15
|
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 <dam...@gm... > <mailto:dam...@gm...>> wrote: > > On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux > > <nel...@gm... <mailto:nel...@gm...>> wrote: > >> > >> > >> On 15 October 2012 06:10, Eric Firing <ef...@ha... > <mailto: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... > <mailto: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 > > > > > ------------------------------------------------------------------------------ > > 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 > > Mat...@li... > <mailto:Mat...@li...> > > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
