Re: [matplotlib-devel] PEP8 github label
On 2012/10/14 12:17 AM, Damon McDougall wrote: > On Sun, Oct 14, 2012 at 2:23 AM, Eric Firing wrote: >> That would be my preference; but has Mike written anything about where PEP8 >> changes should go? > > All I can find is this: https://github.com/matplotlib/matplotlib/pull/1153 > Thanks. It's better than nothing, but hardly crystal-clear as guidance for the present situation. Mike's idea, as a compromise, was to "put some cleanup things (such as this) prior to the RC" but after creation of the branch. It is now well past rc3. It seems to me that putting such massive changes in now means that we should get them all in, then have another RC, and then wait a while. In addition, if this is to be the course of action, I think it would be better to rebase each PR against v1.2.x prior to review and merging so that we can be inspecting exactly the changes that will be made to v1.2.x, instead of cherry-picking. I did ask Mike earlier about cherry-picking backwards versus merging maintenance into master, and he confirmed that the latter remained the normal practice. My first choice would still be to not put any of the PEP8 things in 1.2.x, and absolutely minimize future changes on 1.2.x, freezing it ASAP. 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
[matplotlib-devel] strategy for 1.2.x, master, PEP8 changes
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 -- 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
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 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes
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? > I didn't know there were any; but anything that far back should be left alone, because subsequent things are based on it, and it has been getting tested along the way during the rc cycle. My concern is with massive changes shortly before release, and about getting the release over and done with so we can move on. 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
Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes
On 14 October 2012 21:22, Eric Firing wrote: > 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. I'm not familiar with matplotlib's merge strategy, but I'd agree with you that making those changes post-RC doesn't sound sensible. There's always the chance of something getting broken, especially when diffs get too big to review carefully. Thomas -- 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
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. 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
Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes
On 2012/10/14 4:49 PM, 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 think that has been the case; certainly it has been the general intention. I put in the remark you quoted in case there might have been one or two small exceptions. Eric > > 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
Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes
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] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
