Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 03/04/2014 06:46 PM, Larry Hastings wrote: On 03/04/2014 03:59 PM, Barry Warsaw wrote: I too would like an rc3, especially to see if issue 19021 can be fixed, which I suspect will hit a lot of people. I talked to the other guys on the 3.4 team, and we're all willing to do an rc3 this weekend. I'll add that to PEP 429. In other news, I'm thrilled to confirm something Antoine mentioned a week or two ago: it is literally impossible for garden-variety core devs to push new branches back into trunk. I tried to, early this morning (PST), with someone logged in to hg.python.org ready to clean up in case it actually worked. But happily hg hooks on the server reject new branches every time. Since this banishes my chief objection to publishing the repo where I do my cherry picking, I'll be publishing that repo this week. I think I still have a rebase ahead of me, so I'm going wait until after the latest (and hopefully last!) round of cherry-picking. I'll post to python-dev once the tree is public. Thanks, Larry! I know I have no idea how much work it takes to be an RM, but I appreciate you taking the time, learning the ropes, and getting this done for the rest of us. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 5 Mar 2014 12:48, Larry Hastings la...@hastings.org wrote: On 03/04/2014 03:59 PM, Barry Warsaw wrote: I too would like an rc3, especially to see if issue 19021 can be fixed, which I suspect will hit a lot of people. I talked to the other guys on the 3.4 team, and we're all willing to do an rc3 this weekend. I'll add that to PEP 429. Thanks Larry, I just saw that commit. It's genuinely appreciated! :) In other news, I'm thrilled to confirm something Antoine mentioned a week or two ago: it is literally impossible for garden-variety core devs to push new branches back into trunk. I tried to, early this morning (PST), with someone logged in to hg.python.org ready to clean up in case it actually worked. But happily hg hooks on the server reject new branches every time. Ah, *now* I understand your concern - yes, that hook was put in place during the initial migration to Mercurial, but if you weren't aware of it, then your desire to keep the release clone offline to prevent erroneous pushes makes a lot more sense to me :) Since this banishes my chief objection to publishing the repo where I do my cherry picking, I'll be publishing that repo this week. I think I still have a rebase ahead of me, so I'm going wait until after the latest (and hopefully last!) round of cherry-picking. I'll post to python-dev once the tree is public. Sweet, thanks! Cheers, Nick. /arry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
Le 05/03/2014 03:46, Larry Hastings a écrit : On 03/04/2014 03:59 PM, Barry Warsaw wrote: I too would like an rc3, especially to see if issue 19021 can be fixed, which I suspect will hit a lot of people. I talked to the other guys on the 3.4 team, and we're all willing to do an rc3 this weekend. I'll add that to PEP 429. In other news, I'm thrilled to confirm something Antoine mentioned a week or two ago: it is literally impossible for garden-variety core devs to push new branches back into trunk. I tried to, early this morning (PST), with someone logged in to hg.python.org ready to clean up in case it actually worked. But happily hg hooks on the server reject new branches every time. And I thought the hook would be overkill! Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 6 Mar 2014 01:32, Antoine Pitrou solip...@pitrou.net wrote: Le 05/03/2014 03:46, Larry Hastings a écrit : On 03/04/2014 03:59 PM, Barry Warsaw wrote: I too would like an rc3, especially to see if issue 19021 can be fixed, which I suspect will hit a lot of people. I talked to the other guys on the 3.4 team, and we're all willing to do an rc3 this weekend. I'll add that to PEP 429. In other news, I'm thrilled to confirm something Antoine mentioned a week or two ago: it is literally impossible for garden-variety core devs to push new branches back into trunk. I tried to, early this morning (PST), with someone logged in to hg.python.org ready to clean up in case it actually worked. But happily hg hooks on the server reject new branches every time. And I thought the hook would be overkill! I found it to be quite a handy failsafe in the early days of using Mercurial. Haven't triggered it since I set up my separate sandbox repo, though :) Cheers, Nick. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
Quoting Nick Coghlan ncogh...@gmail.com: If you don't want to do an rc3 despite the cherry picked changes since rc2, then you need to make it easy for people to test the changes directly from the release branch. An opaque intermittently updated tarball is not acceptable when none of our infrastructure is designed to work that way. I was OK with just the tarball when I assumed you would an rc3 if non-trivial defects were found in rc2. If that's not the case, then we *need* a public mirror of your release clone. Another rc or not - I expect to see a 3.4.1 release *really* shortly after the 3.4.0 release. So except for issues where Python does not work at all, any glitches that remain in the code can be fixed in the bug fix release. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 4 March 2014 20:16, mar...@v.loewis.de wrote: Quoting Nick Coghlan ncogh...@gmail.com: If you don't want to do an rc3 despite the cherry picked changes since rc2, then you need to make it easy for people to test the changes directly from the release branch. An opaque intermittently updated tarball is not acceptable when none of our infrastructure is designed to work that way. I was OK with just the tarball when I assumed you would an rc3 if non-trivial defects were found in rc2. If that's not the case, then we *need* a public mirror of your release clone. Another rc or not - I expect to see a 3.4.1 release *really* shortly after the 3.4.0 release. So except for issues where Python does not work at all, any glitches that remain in the code can be fixed in the bug fix release. Right, but I don't see the need to rush 3.4.0 itself - these were definitely edge cases (that's why our test suite missed them), but they were a result of two of the deeper changes in 3.4 (the import system changes and the introspection changes). Mike and Armin found, investigated and reported them when testing on rc2 turned up a couple of relatively obscure and hard to diagnose failures in their own test suites, and it seems discourteous to then turn around and put pressure on them to double check the fix in our original release time frame rather than granting the extra two weeks a 3rd rc would provide not just to us, but to anyone doing third party testing. (Barry and Matthias already confirmed we can do that much while still having the final release make it directly in Ubuntu 14.04) Maybe I'm being overly conservative, and if Larry, you, and Ned are all comfortable with the idea of going straight to a final release from here, I'm not going to argue further (since you're the ones that would incur the additional work from an additional release). I just wanted to be clear that I'd be more comfortable with either a 3rd release candidate given the pip installation, pkgutil type slot introspection changes I'm aware of, or at least the ability for people to test the in-development final release using the usual processes documented in the devguide. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
Hi, 2014-03-03 22:38 GMT+01:00 Nick Coghlan ncogh...@gmail.com: Related question - have you decided yet whether or not to do an rc3? I take a look at current release blocker issues for Python 3.4. I saw bugfixes (ex: upgrade SQLite from 3.8.3 to 3.8.3.1) but also fixes for regressions between Python 3.4rc2 and Python 3.4rc1, especially about pip on Windows. It looks like the Windows installer *and* pip are currently broken on Windows with Python 3.4rc2. It would be sad to release Python 3.4 with pip broken (on Windows) since it was announced (*) that Python 3.4 finally fixes the pip bootstrap issue, and users may expect this feature. If we fix the Windows installer and pip on Windows, it would be safer to have a RC3 because I don't know how to test Windows installer and I don't want to learn how to do that. Note: There are also requested changes in OS X installer (upgrade SQLite). IMO a perfect final version is exactly the same than the last RC except that the version changed. Here I see a long list of cherry-pick issues... @Larry: What do you think of a RC3 for March 16th, and a final release one week later (March 23th)? (Or maybe a RC3 for this week-end if you have some free time :-)) (*) Read for example https://lwn.net/Articles/570471/ Rationalizing Python packaging Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On Tue, 04 Mar 2014 11:16:41 +0100 mar...@v.loewis.de wrote: Quoting Nick Coghlan ncogh...@gmail.com: If you don't want to do an rc3 despite the cherry picked changes since rc2, then you need to make it easy for people to test the changes directly from the release branch. An opaque intermittently updated tarball is not acceptable when none of our infrastructure is designed to work that way. I was OK with just the tarball when I assumed you would an rc3 if non-trivial defects were found in rc2. If that's not the case, then we *need* a public mirror of your release clone. Another rc or not - I expect to see a 3.4.1 release *really* shortly after the 3.4.0 release. So except for issues where Python does not work at all, any glitches that remain in the code can be fixed in the bug fix release. I agree with Martin. At this point, we'd better release 3.4.0 (fixing any critical regressions, but leaving non-critical ones aside), then patiently collect evidence of issues, and fix them in non-rush mode for 3.4.1. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On Tue, Mar 4, 2014 at 8:33 AM, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 04 Mar 2014 11:16:41 +0100 mar...@v.loewis.de wrote: Quoting Nick Coghlan ncogh...@gmail.com: If you don't want to do an rc3 despite the cherry picked changes since rc2, then you need to make it easy for people to test the changes directly from the release branch. An opaque intermittently updated tarball is not acceptable when none of our infrastructure is designed to work that way. I was OK with just the tarball when I assumed you would an rc3 if non-trivial defects were found in rc2. If that's not the case, then we *need* a public mirror of your release clone. Another rc or not - I expect to see a 3.4.1 release *really* shortly after the 3.4.0 release. So except for issues where Python does not work at all, any glitches that remain in the code can be fixed in the bug fix release. I agree with Martin. At this point, we'd better release 3.4.0 (fixing any critical regressions, but leaving non-critical ones aside), then patiently collect evidence of issues, and fix them in non-rush mode for 3.4.1. How about this (if Larry is amenable): critical now/this week (e.g. pip on Windows works), non-critical in 3.4.1 with Larry aiming to release 3.4.1 by the end of April? That way the PyCon sprints can be used by projects to test against 3.4.1 and the core sprint can work on squashing any bugs that will inevitably come up from 3.4.0 being out the door. This also lets us make our stated 3.4.0 release date. Every release we feel pressure to squeeze on those last few bugs and this release is the same. Heck, you can say it's enhanced as we had a longer rc cycle. Normally the bugs from Armin and Mike -- which I appreciate -- would have just happened after 3.4.0 went out the door and thus be rolled into 3.4.1 anyway. I suspect the community in general views *.0 releases as stable but not perfect while *.1 releases as the solid one where no surprises will pop up because of new code. I have also filed http://bugs.python.org/issue20851 to make sure the devguide covers running tests from a tarball. If the way the release has been handled has still bugged you enough it can be discussed at the language summit, but it would be the first time we consider putting any restrictions on the RM (which I would loathe to do; I'm fine with nudging Larry to do his stuff in public next time in hopes he's more comfortable with the whole process, but I wouldn't want to require it). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
Am 04.03.2014 15:52, schrieb Brett Cannon: I have also filed http://bugs.python.org/issue20851 to make sure the devguide covers running tests from a tarball. If the way the release has been handled has still bugged you enough it can be discussed at the language summit, but it would be the first time we consider putting any restrictions on the RM. I wouldn't put it this way, but instead ask how to enable the RM to do this kind of work more publicly. I really would like it more if we can extend our buildd infrastructure to automatically test during the time where the trunk and the release candidates don't match. I am aware that this was never done for any release in the past, but maybe this is something that can be enabled for 3.5. But before documenting a process which may change depending on the RM why not try to align the process? Matthias ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 5 Mar 2014 08:15, Matthias Klose d...@ubuntu.com wrote: Am 04.03.2014 15:52, schrieb Brett Cannon: I have also filed http://bugs.python.org/issue20851 to make sure the devguide covers running tests from a tarball. If the way the release has been handled has still bugged you enough it can be discussed at the language summit, but it would be the first time we consider putting any restrictions on the RM. I wouldn't put it this way, but instead ask how to enable the RM to do this kind of work more publicly. I really would like it more if we can extend our buildd infrastructure to automatically test during the time where the trunk and the release candidates don't match. I am aware that this was never done for any release in the past, but maybe this is something that can be enabled for 3.5. But before documenting a process which may change depending on the RM why not try to align the process? I think it's also the fact that new feature releases are rare and changes of release manager even more so, meaning there's a fair bit of relearning involved every time (since what was appropriate a couple of years earlier may not be appropriate the next time, and we'll usually have new developers involved that weren't around for the previous release). While I'd still strongly prefer an rc3, I think we at least need to get the remaining release blockers sorted in the tracker (either fixing them or reclassifying them, or else closing them if they're a rejected cherry pick request) and a tarball or release clone available for core developer and third party testing. We won't be able to get people to test the pip integration fixes on Windows that way (that's one of the reasons I would like an rc3 and don't understand the apparent desire to avoid one), but we would at least be able to check that the Flask and Alembic test suites pass. I'm being fussy about this for two reasons. Firstly, because my view is the same as Victor's: the time between the last rc and the final release should be completely uninteresting, with no significant regressions reported relative to the previous major version (or any such cases clearly being rare enough to wait for the first maintenance release). Secondly, I care because I think we need to take into account the social benefits of ensuring that we treat third party testers as valued members of the release process by giving them a clear chance to confirm that the problems they reported have been addressed before we proceed with the release. That third party testing does help improve the stability of the final release, and wherever practical, we should be doing our best to encourage it. For 3.4rc2, the Alembic and Flask test suites both hit clear regression bugs (one due to pkgutil still calling a now deprecated function, the other due to a type slot publishing an incorrect signature), and users also found that upgrading pip on Windows would prevent subsequently uninstalling CPython. I can politely ask Mike and Armin to test against a pre-release tarball, or against the default branch and assure them the patch has been included in the release tag, but I have no reasonable answer to give them if they ask why not just publish an rc3 to make this easy to test?. For the folks that reported the Windows installer issues, we can't ask them to double check the fixes at all if we don't do an rc3. Regards, Nick. Matthias ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On Mar 05, 2014, at 09:24 AM, Nick Coghlan wrote: I think it's also the fact that new feature releases are rare and changes of release manager even more so, meaning there's a fair bit of relearning involved every time (since what was appropriate a couple of years earlier may not be appropriate the next time, and we'll usually have new developers involved that weren't around for the previous release). This is true. Be aware though that Larry is in communication with Benjamin, Georg, and myself, and the PSU is running a closed mailing list for past, present, and future wink release managers[1]. But you're right that the process and tools can change fairly significantly between releases, and certainly between release manager stints. We have PEP 101 and a bunch of scripts to automate as much as possible. I'm fully supportive of RMs taking on at least two releases in a row, for a similar reason it makes sense to hold PyconNA's in the same city more than one year in a row. Larry has to figure out what works for him on the fly, and I'm positive that he takes everyone's comments and feedback seriously. RMing is just not that easy. Hopefully, once the heat of the release subsides, we and Larry can review the process and make whatever changes are necessary for next time. While I'd still strongly prefer an rc3, I think we at least need to get the remaining release blockers sorted in the tracker (either fixing them or reclassifying them, or else closing them if they're a rejected cherry pick request) and a tarball or release clone available for core developer and third party testing. I too would like an rc3, especially to see if issue 19021 can be fixed, which I suspect will hit a lot of people. Despite Serhiy's comment (msg212475) I haven't quite gotten the Ubuntu package working entirely, and I hope to return to it once I have some other unrelated high priority issues resolved. It's fine to close as rejected any cherry picks that won't make it into 3.4.0. For the related bugs that are fixed in trunk though, those marked as release blockers should IMO be demoted to deferred blockers so they can be handled in 3.4.1. (Unless of course the disposition is to not fix them until 3.5). I'm being fussy about this for two reasons. Firstly, because my view is the same as Victor's: the time between the last rc and the final release should be completely uninteresting, with no significant regressions reported relative to the previous major version (or any such cases clearly being rare enough to wait for the first maintenance release). I completely agree. I don't even trust seemingly innocent changes -- they have broken us before! Ideally, the only difference between the last rc and the final release is the version bump. That may or may not be possible. Secondly, I care because I think we need to take into account the social benefits of ensuring that we treat third party testers as valued members of the release process by giving them a clear chance to confirm that the problems they reported have been addressed before we proceed with the release. That third party testing does help improve the stability of the final release, and wherever practical, we should be doing our best to encourage it. Given how difficult it is to get people to test pre-final release versions, I definitely agree we need to encourage and support enthusiastic third parties. We all want to avoid the brown paper bag release. ;) Cheers, -Barry [1] Both the PSU and this mailing list emphatically do not exist. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 03/04/2014 03:59 PM, Barry Warsaw wrote: I too would like an rc3, especially to see if issue 19021 can be fixed, which I suspect will hit a lot of people. I talked to the other guys on the 3.4 team, and we're all willing to do an rc3 this weekend. I'll add that to PEP 429. In other news, I'm thrilled to confirm something Antoine mentioned a week or two ago: it is literally impossible for garden-variety core devs to push new branches back into trunk. I tried to, early this morning (PST), with someone logged in to hg.python.org ready to clean up in case it actually worked. But happily hg hooks on the server reject new branches every time. Since this banishes my chief objection to publishing the repo where I do my cherry picking, I'll be publishing that repo this week. I think I still have a rebase ahead of me, so I'm going wait until after the latest (and hopefully last!) round of cherry-picking. I'll post to python-dev once the tree is public. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 03/03/2014 03:01 AM, Victor Stinner wrote: Hi, I would like to know if the cherry-picking rule still applies for Python 3.4 final? Can I open an issue if I want to see a changeset in the final version? Sadly, yes. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
2014-03-03 13:13 GMT+01:00 Larry Hastings la...@hastings.org: I would like to know if the cherry-picking rule still applies for Python 3.4 final? Can I open an issue if I want to see a changeset in the final version? Sadly, yes. Ok, I created: http://bugs.python.org/issue20843 Why do you say sadly? It's up to you to decide if a change can wait Python 3.4.1 or not. Feel free to close my cherry-pick issue as wontfix. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 3/3/2014 7:13 AM, Larry Hastings wrote: On 03/03/2014 03:01 AM, Victor Stinner wrote: Hi, I would like to know if the cherry-picking rule still applies for Python 3.4 final? Can I open an issue if I want to see a changeset in the final version? Sadly, yes. Doc changes appear online within hours. I should expect that releases pull in and bundle the latest version of the doc possible, just before the release. Is this not the usual procedure? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
Am 03.03.2014 19:31, schrieb Terry Reedy: On 3/3/2014 7:13 AM, Larry Hastings wrote: On 03/03/2014 03:01 AM, Victor Stinner wrote: Hi, I would like to know if the cherry-picking rule still applies for Python 3.4 final? Can I open an issue if I want to see a changeset in the final version? Sadly, yes. Doc changes appear online within hours. I should expect that releases pull in and bundle the latest version of the doc possible, just before the release. Is this not the usual procedure? No, that would be mostly pointless churn, with all the usual dangers of last minute changes. Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 03/03/2014 05:05 AM, Victor Stinner wrote: 2014-03-03 13:13 GMT+01:00 Larry Hastings la...@hastings.org: I would like to know if the cherry-picking rule still applies for Python 3.4 final? Can I open an issue if I want to see a changeset in the final version? Sadly, yes. Ok, I created: http://bugs.python.org/issue20843 Why do you say sadly? It's up to you to decide if a change can wait Python 3.4.1 or not. Feel free to close my cherry-pick issue as wontfix. It was intended as gentle comedy. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 4 Mar 2014 07:32, Larry Hastings la...@hastings.org wrote: On 03/03/2014 05:05 AM, Victor Stinner wrote: 2014-03-03 13:13 GMT+01:00 Larry Hastings la...@hastings.org: I would like to know if the cherry-picking rule still applies for Python 3.4 final? Can I open an issue if I want to see a changeset in the final version? Sadly, yes. Ok, I created: http://bugs.python.org/issue20843 Why do you say sadly? It's up to you to decide if a change can wait Python 3.4.1 or not. Feel free to close my cherry-pick issue as wontfix. It was intended as gentle comedy. Related question - have you decided yet whether or not to do an rc3? I ask, as I believe it would be good to give the folks like Mike Bayer and Armin Ronacher (who picked up test coverage gaps in rc2 via the Alembic and Flask test suites respectively) a chance to rerun their tests before we declare 3.4 final. Cheers, Nick. /arry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 03/03/2014 21:38, Nick Coghlan wrote: On 4 Mar 2014 07:32, Larry Hastings la...@hastings.org mailto:la...@hastings.org wrote: On 03/03/2014 05:05 AM, Victor Stinner wrote: 2014-03-03 13:13 GMT+01:00 Larry Hastings la...@hastings.org mailto:la...@hastings.org: I would like to know if the cherry-picking rule still applies for Python 3.4 final? Can I open an issue if I want to see a changeset in the final version? Sadly, yes. Ok, I created: http://bugs.python.org/issue20843 Why do you say sadly? It's up to you to decide if a change can wait Python 3.4.1 or not. Feel free to close my cherry-pick issue as wontfix. It was intended as gentle comedy. Related question - have you decided yet whether or not to do an rc3? I ask, as I believe it would be good to give the folks like Mike Bayer and Armin Ronacher (who picked up test coverage gaps in rc2 via the Alembic and Flask test suites respectively) a chance to rerun their tests before we declare 3.4 final. Cheers, Nick. Will this impact on the decision http://bugs.python.org/issue20846 ? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On Mar 03, 2014, at 10:36 PM, Mark Lawrence wrote: Will this impact on the decision http://bugs.python.org/issue20846 ? Issue 20808 is my own pet cherry pick for 3.4. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
Will this impact on the decision http://bugs.python.org/issue20846 ? This issue has been closed as wontfix. It has no patch and must be reported to pip, not python. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 4 Mar 2014 08:40, Mark Lawrence breamore...@yahoo.co.uk wrote: On 03/03/2014 21:38, Nick Coghlan wrote: On 4 Mar 2014 07:32, Larry Hastings la...@hastings.org mailto:la...@hastings.org wrote: On 03/03/2014 05:05 AM, Victor Stinner wrote: 2014-03-03 13:13 GMT+01:00 Larry Hastings la...@hastings.org mailto:la...@hastings.org: I would like to know if the cherry-picking rule still applies for Python 3.4 final? Can I open an issue if I want to see a changeset in the final version? Sadly, yes. Ok, I created: http://bugs.python.org/issue20843 Why do you say sadly? It's up to you to decide if a change can wait Python 3.4.1 or not. Feel free to close my cherry-pick issue as wontfix. It was intended as gentle comedy. Related question - have you decided yet whether or not to do an rc3? I ask, as I believe it would be good to give the folks like Mike Bayer and Armin Ronacher (who picked up test coverage gaps in rc2 via the Alembic and Flask test suites respectively) a chance to rerun their tests before we declare 3.4 final. Cheers, Nick. Will this impact on the decision http://bugs.python.org/issue20846 ? No. I never claimed pip was bug free (any more than CPython itself is), merely the best available option. File a bug against pip (assuming there isn't one already), get it fixed, and we'll bundle the fixed version with the next CPython maintenance release. Cheers, Nick. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 03/03/2014 01:38 PM, Nick Coghlan wrote: Related question - have you decided yet whether or not to do an rc3? I ask, as I believe it would be good to give the folks like Mike Bayer and Armin Ronacher (who picked up test coverage gaps in rc2 via the Alembic and Flask test suites respectively) a chance to rerun their tests before we declare 3.4 final. I hadn't planned on it. I'll reach out to those two and see if they can deal with tarballs, rather than requiring binary installers--if tarballs works for them, I'll steer them towards the 3.4 merge status tarballs and ping them when I spin up some new ones. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 4 March 2014 13:35, Larry Hastings la...@hastings.org wrote: On 03/03/2014 01:38 PM, Nick Coghlan wrote: Related question - have you decided yet whether or not to do an rc3? I ask, as I believe it would be good to give the folks like Mike Bayer and Armin Ronacher (who picked up test coverage gaps in rc2 via the Alembic and Flask test suites respectively) a chance to rerun their tests before we declare 3.4 final. I hadn't planned on it. I'll reach out to those two and see if they can deal with tarballs, rather than requiring binary installers--if tarballs works for them, I'll steer them towards the 3.4 merge status tarballs and ping them when I spin up some new ones. All of our development guides for testing against trunk are designed around running from a Mercurial checkout - it would *really* be whole lot easier for everyone else that is trying to test the release if you could just do a push from your release clone to a server side clone on hg.python.org (the link to create one is on http://hg.python.org/cpython/, and then it's just a hg push to publish a mirror of the exact state of your current clone). If you don't want to do an rc3 despite the cherry picked changes since rc2, then you need to make it easy for people to test the changes directly from the release branch. An opaque intermittently updated tarball is not acceptable when none of our infrastructure is designed to work that way. I was OK with just the tarball when I assumed you would an rc3 if non-trivial defects were found in rc2. If that's not the case, then we *need* a public mirror of your release clone. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 03/03/2014 07:58 PM, Nick Coghlan wrote: All of our development guides for testing against trunk are designed around running from a Mercurial checkout - it would *really* be whole lot easier for everyone else that is trying to test the release if you could just do a push from your release clone to a server side clone on hg.python.org (the link to create one is on http://hg.python.org/cpython/, and then it's just a hg push to publish a mirror of the exact state of your current clone). I've pulled enough shenanigans over here (discarding and recreating the 3.4 branch, rebasing) that I'm really glad I haven't made the revisions public. And I'm not done, either, *yet another* really old revision has cropped up for cherry-picking. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 4 March 2014 14:20, Larry Hastings la...@hastings.org wrote: On 03/03/2014 07:58 PM, Nick Coghlan wrote: All of our development guides for testing against trunk are designed around running from a Mercurial checkout - it would *really* be whole lot easier for everyone else that is trying to test the release if you could just do a push from your release clone to a server side clone on hg.python.org (the link to create one is on http://hg.python.org/cpython/, and then it's just a hg push to publish a mirror of the exact state of your current clone). I've pulled enough shenanigans over here (discarding and recreating the 3.4 branch, rebasing) that I'm really glad I haven't made the revisions public. And I'm not done, either, *yet another* really old revision has cropped up for cherry-picking. The clones doesn't need to be updatable, we just need an easy way to do hg clone URL to get a release branch to test against. It doesn't matter if hg pull doesn't work later - we just need you to make it as easy as possible for us to help you test things, because if there's not going to be an rc3 then we're running out of time to make sure SQL Alchemy and Flask actually work properly on Python 3.4 final (and I've been told the pkgutil bug that affected Flask may have affected Vim as well). Let *us* deal with the Mercurial problems - you can rebase and cherry pick however the heck you want. But at the moment you're making it *hard* for people to test the release, and that is scaring me - our test coverage is a long way from 100%, so we *need* people running third party test suites on the pre-release to spot coverage gaps the way the Alembic and Flask test suites did. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 03/03/2014 10:23 PM, Nick Coghlan wrote: But at the moment you're making it *hard* for people to test the release, How? How is testing against a tarball fundamentally different from testing against an hg-cloned repository? I'm really not buying this. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 4 March 2014 16:50, Larry Hastings la...@hastings.org wrote: On 03/03/2014 10:23 PM, Nick Coghlan wrote: But at the moment you're making it *hard* for people to test the release, How? How is testing against a tarball fundamentally different from testing against an hg-cloned repository? I'm really not buying this. Because there are *zero* instructions in the devguide for tarball based testing. Can it be done? Yes. Is it properly documented such that it is acceptable to rely on it as an essential part of the release process? No. *Never* have we done a feature release where we went dark for most of the release candidate cycle - for past feature releases, the release branch was made at the time of the first rc, and everything merged during that time was subject to two committer review, and everything merged to the release branch was automatically considered as a candidate for including in the next rc/final release. After the switch to Mercurial, the contents of the release branch might not be *exactly* what ended up being released, but they were close enough for all the purposes that anyone cared about. That's not the case here - by instituting the new process where you stopped checking every commit and instead required the creation of specific tracker issues, the default branch of the main repo now has a bunch of stuff listed for 3.4.1 that is a mixture of 3.4.0 and 3.4.1 changes, so it's hard to tell whether or not a particular change is going to make it into 3.4 final. I was prepared to go along with that (since those that do the work get to make the rules), but then you said you were going to go straight from a release candidate that broke two of the most popular Python projects to a final release with the release clone *still* offline for reasons I do not understand. That is *not* OK - if we're skipping rc3 even though rc2 broke both Flask and SQL Alchemy (and possibly Vim), then we need to be able to see *exactly* what is going to be published, including the full history of which commits have been cherry-picked, not just the end result as a tarball. You've given people plenty of warning that you'll be rewriting history in your release clone. That's fine, we can deal, especially for throwaway testing clones - git users handle rewritten history as a matter of course, and it really isn't that scary, even in Mercurial. But the combination of skipping rc3 *and* keeping the release clone offline is not a responsible course of action. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
