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