Right now we're in the "release candidate" phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2.
You might think that anything you check in to the "default" branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to "default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships!
If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final, please go to the issue tracker and create a new issue with the following attributes:
The title should start with "3.4 cherry-pick: " followed by the revision id and a short summary example: "3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix" The version should be "Python 3.4" The assignee should be "larry" The priority should be "release blocker" The comment should *also* contain the revision id (the tracker will turn it into a link)
I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here:
http://www.midwinter.com/%7Elarry/3.4.merge.status.html
The page is marked "beta" because it doesn't have real data yet--I'm still experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked "merged" on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning.
(By the way: on that page, clicking on a revision takes you to the revision web page. Clicking on the first line of the comment expands it to show the complete comment.)
Please use your best judgment before asking that a revision be cherry-picked into 3.4.0. Our goal in the release candidate phase is to stabilize Python, and to do that we must stop changing it. Only important interface changes, new features, or bugfixes should be checked in now, and preferably they should be low-risk.
Cheers,
//arry/
http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here & on the issue to make sure it's not missed...
Paul
On 16 February 2014 23:25, Larry Hastings larry@hastings.org wrote:
Right now we're in the "release candidate" phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2.
You might think that anything you check in to the "default" branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to "default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships!
If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final, please go to the issue tracker and create a new issue with the following attributes:
The title should start with "3.4 cherry-pick: " followed by the revision id and a short summary example: "3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix" The version should be "Python 3.4" The assignee should be "larry" The priority should be "release blocker" The comment should *also* contain the revision id (the tracker will turn it into a link)
I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here:
http://www.midwinter.com/%7Elarry/3.4.merge.status.html
The page is marked "beta" because it doesn't have real data yet--I'm still experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked "merged" on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning.
(By the way: on that page, clicking on a revision takes you to the revision web page. Clicking on the first line of the comment expands it to show the complete comment.)
Please use your best judgment before asking that a revision be cherry-picked into 3.4.0. Our goal in the release candidate phase is to stabilize Python, and to do that we must stop changing it. Only important interface changes, new features, or bugfixes should be checked in now, and preferably they should be low-risk.
Cheers,
/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/p.f.moore%40gmail.com
For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a.
On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore p.f.moore@gmail.com wrote:
http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here & on the issue to make sure it's not missed...
Paul
On 16 February 2014 23:25, Larry Hastings larry@hastings.org wrote:
Right now we're in the "release candidate" phase of 3.4. 3.4.0 rc1 has
been
released, and the next release will be rc2.
You might think that anything you check in to the "default" branch in
Python
trunk will go into 3.4.0 rc2, and after that ships, checkins would go
into
3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in
to
"default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0
final
will by default go into 3.4.1. Only fixes that I cherry-pick into my
local
branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships!
If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or
final,
please go to the issue tracker and create a new issue with the following attributes:
The title should start with "3.4 cherry-pick: " followed by the revision
id
and a short summary example: "3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix" The version should be "Python 3.4" The assignee should be "larry" The priority should be "release blocker" The comment should *also* contain the revision id (the tracker will turn
it
into a link)
I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here:
http://www.midwinter.com/%7Elarry/3.4.merge.status.html
The page is marked "beta" because it doesn't have real data yet--I'm
still
experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked
"merged"
on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning.
(By the way: on that page, clicking on a revision takes you to the
revision
web page. Clicking on the first line of the comment expands it to show
the
complete comment.)
Please use your best judgment before asking that a revision be
cherry-picked
into 3.4.0. Our goal in the release candidate phase is to stabilize
Python,
and to do that we must stop changing it. Only important interface
changes,
new features, or bugfixes should be checked in now, and preferably they should be low-risk.
Cheers,
/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/p.f.moore%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/greg%40krypto.org
http://bugs.python.org/issue20651 filed to track this as larry requested.
On Sun, Feb 16, 2014 at 7:09 PM, Gregory P. Smith greg@krypto.org wrote:
For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a.
On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore p.f.moore@gmail.com wrote:
http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here & on the issue to make sure it's not missed...
Paul
On 16 February 2014 23:25, Larry Hastings larry@hastings.org wrote:
Right now we're in the "release candidate" phase of 3.4. 3.4.0 rc1 has
been
released, and the next release will be rc2.
You might think that anything you check in to the "default" branch in
Python
trunk will go into 3.4.0 rc2, and after that ships, checkins would go
into
3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in
to
"default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0
final
will by default go into 3.4.1. Only fixes that I cherry-pick into my
local
branch will go into 3.4.0 rc2 and final. And my local branch will
remain
private until 3.4.0 final ships!
If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or
final,
please go to the issue tracker and create a new issue with the following attributes:
The title should start with "3.4 cherry-pick: " followed by the
revision id
and a short summary example: "3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix" The version should be "Python 3.4" The assignee should be "larry" The priority should be "release blocker" The comment should *also* contain the revision id (the tracker will
turn it
into a link)
I'm also working on automatically publishing the merged/unmerged
revision
status to a web page. You can see a mock-up here:
http://www.midwinter.com/%7Elarry/3.4.merge.status.html
The page is marked "beta" because it doesn't have real data yet--I'm
still
experimenting with my automation, so I haven't created the real 3.4
local
branch yet. Again, just to be crystal-clear: the revisions marked
"merged"
on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning.
(By the way: on that page, clicking on a revision takes you to the
revision
web page. Clicking on the first line of the comment expands it to show
the
complete comment.)
Please use your best judgment before asking that a revision be
cherry-picked
into 3.4.0. Our goal in the release candidate phase is to stabilize
Python,
and to do that we must stop changing it. Only important interface
changes,
new features, or bugfixes should be checked in now, and preferably they should be low-risk.
Cheers,
/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/p.f.moore%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/greg%40krypto.org
On 02/16/2014 03:45 PM, Paul Moore wrote:
http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here & on the issue to make sure it's not missed...
If it has an issue number like that, then generally Roundup Robot will notify the issue when something is checked in. And those comments will have the revision id in them.
Also, you can scan the output of "hg log" to find the revision numbers. The first line of each stanza looks like
changeset: 89231:75a12cf63f20
Here, "75a12cf63f20" is the revision id.
//arry/
Thanks, I see. Greg already filed a tracking issue, so it's covered anyway.
On 17 February 2014 15:33, Larry Hastings larry@hastings.org wrote:
On 02/16/2014 03:45 PM, Paul Moore wrote:
http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here & on the issue to make sure it's not missed...
If it has an issue number like that, then generally Roundup Robot will notify the issue when something is checked in. And those comments will have the revision id in them.
Also, you can scan the output of "hg log" to find the revision numbers. The first line of each stanza looks like
changeset: 89231:75a12cf63f20
Here, "75a12cf63f20" is the revision id.
/arry
2014-02-17 0:25 GMT+01:00 Larry Hastings larry@hastings.org:
You might think that anything you check in to the "default" branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to "default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships!
Does it mean that the default branch is open for changes which target 3.4.1?
Victor
On 02/17/2014 03:20 PM, Victor Stinner wrote:
2014-02-17 0:25 GMT+01:00 Larry Hastings larry@hastings.org:
You might think that anything you check in to the "default" branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to "default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships!
Does it mean that the default branch is open for changes which target 3.4.1?
Basically, yes.
//arry/
On 2/17/2014 6:20 PM, Victor Stinner wrote:
2014-02-17 0:25 GMT+01:00 Larry Hastings larry@hastings.org:
You might think that anything you check in to the "default" branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to "default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships!
Does it mean that the default branch is open for changes which target 3.4.1?
Presumably. That is what I started doing today.
However, the top section of 3.4 News says 3.4.0rc2 rather than 3.4.1. It should be relabeled and a 3.4.0rc2 sections with items actually added to 3.4.0c2 (and those items should not be in the 3.4.1 section.
On 02/18/2014 03:38 PM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier.
Is there *any* reason to make this branch public before 3.4.0 final?
//arry/
2014-02-19 0:46 GMT+01:00 Larry Hastings larry@hastings.org:
Is there *any* reason to make this branch public before 3.4.0 final?
I'm a little bit worried by the fact that buildbots will not test it. Cherry-picking many patches is complex. It's safe if you have a very short list of changes.
Would it be insane to use default as the next RC2? It looks like there are too many changes between RC1 and RC2. Another release candidate is maybe needed.
Victor
On 02/18/2014 03:54 PM, Victor Stinner wrote:
2014-02-19 0:46 GMT+01:00 Larry Hastings larry@hastings.org:
Is there *any* reason to make this branch public before 3.4.0 final?
I'm a little bit worried by the fact that buildbots will not test it.
"fact"?
http://docs.python.org/devguide/buildbots.html#custom-builders
Would it be insane to use default as the next RC2?
Yes.
//arry/
Am 19.02.2014 01:07, schrieb Larry Hastings:
On 02/18/2014 03:54 PM, Victor Stinner wrote:
2014-02-19 0:46 GMT+01:00 Larry Hastings larry@hastings.org:
Is there *any* reason to make this branch public before 3.4.0 final?
I'm a little bit worried by the fact that buildbots will not test it.
"fact"?
http://docs.python.org/devguide/buildbots.html#custom-builders
And this works without a public repo on hg.python.org how?
Georg
Am 19.02.2014 00:46, schrieb Larry Hastings:
On 02/18/2014 03:38 PM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier.
Is there *any* reason to make this branch public before 3.4.0 final?
- Python is an open source project. Why do we need to hide development for a month or more?
- Not even four eyes looking at the code seems to be odd. You can make mistakes too.
This seems to be a social or a technical problem. I assume making this branch available read-only would address your concerns? Does hg allow this? And if not, why not create this branch in the upstream repository, and tell people not to commit to it? Why shouldn't such a social restriction work? Seems to work well for other projects.
Matthias
On 02/18/2014 03:56 PM, Matthias Klose wrote:
Am 19.02.2014 00:46, schrieb Larry Hastings:
On 02/18/2014 03:38 PM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier.
Is there *any* reason to make this branch public before 3.4.0 final?
Python is an open source project. Why do we need to hide development for a month or more?
Not even four eyes looking at the code seems to be odd. You can make mistakes too.
This seems to be a social or a technical problem. I assume making this branch available read-only would address your concerns? Does hg allow this? And if not, why not create this branch in the upstream repository, and tell people not to commit to it? Why shouldn't such a social restriction work? Seems to work well for other projects.
When you are release manager for Python, you may institute this policy if you like. Right now, I have enough to do as it is.
//arry/
Am 19.02.2014 01:05, schrieb Larry Hastings:
On 02/18/2014 03:56 PM, Matthias Klose wrote:
Am 19.02.2014 00:46, schrieb Larry Hastings:
On 02/18/2014 03:38 PM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier.
Is there *any* reason to make this branch public before 3.4.0 final?
Python is an open source project. Why do we need to hide development for a month or more?
Not even four eyes looking at the code seems to be odd. You can make mistakes too.
This seems to be a social or a technical problem. I assume making this branch available read-only would address your concerns? Does hg allow this? And if not, why not create this branch in the upstream repository, and tell people not to commit to it? Why shouldn't such a social restriction work? Seems to work well for other projects.
When you are release manager for Python, you may institute this policy if you like. Right now, I have enough to do as it is.
is it too much to ask for a public mirror / tarball / something of this branch? This seems to be a minor effort compared to the clinic work that went into 3.4.
Matthias
On 02/18/2014 04:19 PM, Matthias Klose wrote:
Am 19.02.2014 01:05, schrieb Larry Hastings:
On 02/18/2014 03:56 PM, Matthias Klose wrote:
Am 19.02.2014 00:46, schrieb Larry Hastings:
On 02/18/2014 03:38 PM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier.
Is there *any* reason to make this branch public before 3.4.0 final?
Python is an open source project. Why do we need to hide development for a month or more?
Not even four eyes looking at the code seems to be odd. You can make mistakes too.
This seems to be a social or a technical problem. I assume making this branch available read-only would address your concerns? Does hg allow this? And if not, why not create this branch in the upstream repository, and tell people not to commit to it? Why shouldn't such a social restriction work? Seems to work well for other projects.
When you are release manager for Python, you may institute this policy if you like. Right now, I have enough to do as it is.
is it too much to ask for a public mirror / tarball / something of this branch? This seems to be a minor effort compared to the clinic work that went into 3.4.
Why do you need this? What is your use case?
//arry/
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
IMO, no. read-only for !larry sure, but not private.
-Barry
I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...)
Publishing tarballs would prevent this and still let people test the exact code Larry is assembling on their favorite obscure platform.
On Tue, Feb 18, 2014 at 3:54 PM, Barry Warsaw barry@python.org wrote:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
IMO, no. read-only for !larry sure, but not private.
-Barry
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/guido%40python.org
Sounds like you aren't exactly a DVCS fan...
On Tue, Feb 18, 2014 at 8:46 PM, Guido van Rossum guido@python.org wrote:
I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...)
Publishing tarballs would prevent this and still let people test the exact code Larry is assembling on their favorite obscure platform.
On Tue, Feb 18, 2014 at 3:54 PM, Barry Warsaw barry@python.org wrote:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this
branch
private?
IMO, no. read-only for !larry sure, but not private.
-Barry
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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
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/rymg19%40gmail.com
Am 19.02.2014 03:46, schrieb Guido van Rossum:
I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...)
Pushes to hg.python.org repos are fully reversible.
If that is Larry's concern he can even put it on bitbucket, where only he can push by default.
Georg
On Tue, 18 Feb 2014 18:46:16 -0800 Guido van Rossum guido@python.org wrote:
I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...)
I don't think I understand the concern. Why is this different from any other mistake someone may make when pushing code? Also "rebase" is only really ok on private repos, as soon as something is published you should use "merge".
Regards
Antoine.
On 02/19/2014 01:20 PM, Antoine Pitrou wrote:
On Tue, 18 Feb 2014 18:46:16 -0800 Guido van Rossum guido@python.org wrote:
I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...)
I don't think I understand the concern. Why is this different from any other mistake someone may make when pushing code? Also "rebase" is only really ok on private repos, as soon as something is published you should use "merge".
If the branch were private, pushing to it would not count as "publishing", but would still provide the benefit of having a redundant server-side backup of the data. Being able to rebase without fuss is a possible legitimate reason to keep the branch private, which Guido provided in response to Matthias's question:
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
On Tue, Feb 18, 2014, at 03:54 PM, Barry Warsaw wrote:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
IMO, no. read-only for !larry sure, but not private.
I've always published my releasing repo on hg.p.o as releasing/2.7.X. I wasn't aware people actually used it; it's mostly a nice backup for when I rm rf * things in anger... :)
Am 19.02.2014 00:54, schrieb Barry Warsaw:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
IMO, no. read-only for !larry sure, but not private.
I emphatically agree. There is no need at all for secrecy, or paranoia.
And it is very understandable that vendors (or even "just" our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release.
Georg
On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.brandl@gmx.net wrote:
Am 19.02.2014 00:54, schrieb Barry Warsaw:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this
branch
private?
IMO, no. read-only for !larry sure, but not private.
I emphatically agree. There is no need at all for secrecy, or paranoia.
And it is very understandable that vendors (or even "just" our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release.
That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Give Larry some trust and freedom to do things in the way that makes him comfortable.
On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote:
That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Give Larry some trust and freedom to do things in the way that makes him comfortable.
I totally agree that Larry should be given fairly wide discretion. He's also feeling out his first big release and deserves some slack.
However, I think Matthias wants read access to the release repo because he's *also* cherry picking patches into Ubuntu's archive. We're already seeing some problems, which we want to investigate, and Matthias has also performed archive-wide test rebuilds to find Python 3.4 incompatibilities in 3rd party libraries, most of which we'd like to fix (e.g. main packages, if its not possible to get to everything in universe).
Matthias just switched the default for Ubuntu 14.04 to Python 3.4 by default, so this is a great test bed to find problems.
Cheers, -Barry
On Wed, Feb 19, 2014 at 8:16 AM, Barry Warsaw barry@python.org wrote:
On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote:
That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Give Larry some trust and freedom to do
things
in the way that makes him comfortable.
I totally agree that Larry should be given fairly wide discretion. He's also feeling out his first big release and deserves some slack.
Thanks for the support!
However, I think Matthias wants read access to the release repo because he's
*also* cherry picking patches into Ubuntu's archive. We're already seeing some problems, which we want to investigate, and Matthias has also performed archive-wide test rebuilds to find Python 3.4 incompatibilities in 3rd party libraries, most of which we'd like to fix (e.g. main packages, if its not possible to get to everything in universe).
Again, this is what RC2 is for (and RC1, for that matter; apart from 20+ asyncio patches there really isn't much of a difference between RC1 and RC2). Larry may legitimately feel uncomfortable with what he's got on his local drive and prefer to tweak some things before telling people "go ahead test with this" -- the difference is that if he was working on new *code*, he could just not commit his work-in-progress, but since here he is assembling the final sequence of *revisions*, he prefers just not to push. (Georg alluded to the fact that you can undo changes in a public repo after they've been pushed, but I suspect he's referring to hg backout, which creates extra revisions, rather than a remote version of hg strip, which would go against the philosophy of DVCS. Either way, Larry's use of Hg is a totally legitimate workflow.)
Matthias just switched the default for Ubuntu 14.04 to Python 3.4 by default, so this is a great test bed to find problems.
And that's great, of course. But what is really gained by giving Larry trouble over a few days' worth of delay, at most?
Am 19.02.2014 16:50, schrieb Guido van Rossum:
On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl <g.brandl@gmx.net mailto:g.brandl@gmx.net> wrote:
Am 19.02.2014 00:54, schrieb Barry Warsaw: > On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: > >>Am 17.02.2014 00:25, schrieb Larry Hastings: >>> And my local branch will remain private until 3.4.0 final ships! >> >>sorry, but this is so wrong. Is there *any* reason why to keep this branch >>private? > > IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even "just" our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release.That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add?
Ned told me just a few days ago that he does regular pre-tag builds of the OSX installers, and as for the Debian/Ubuntu side Barry can say more. The thing with the RCs is that as long as you add patches during the RC phase (which is more or less unavoidable if the schedule is to be kept), the state of the release branch can only profit from more eyes.
Give Larry some trust and freedom to do things in the way that makes him comfortable.
I have no doubts that Larry will make 3.4 the best Python yet :) So far he has discussed most of his procedures with us, so I don't see a reason not to weigh in here.
Georg
Am 19.02.2014 19:00, schrieb Georg Brandl:
Give Larry some trust and freedom to do things in the way that makes him comfortable.
I have no doubts that Larry will make 3.4 the best Python yet :) So far he has discussed most of his procedures with us, so I don't see a reason not to weigh in here.
NB, "us" being the previous release managers.
Georg
Am 19.02.2014 19:00, schrieb Georg Brandl:
Am 19.02.2014 16:50, schrieb Guido van Rossum:
On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl <g.brandl@gmx.net mailto:g.brandl@gmx.net> wrote:
Am 19.02.2014 00:54, schrieb Barry Warsaw: > On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: > >>Am 17.02.2014 00:25, schrieb Larry Hastings: >>> And my local branch will remain private until 3.4.0 final ships! >> >>sorry, but this is so wrong. Is there *any* reason why to keep this branch >>private? > > IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even "just" our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release.That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add?
Ned told me just a few days ago that he does regular pre-tag builds of the OSX installers, and as for the Debian/Ubuntu side Barry can say more. The thing with the RCs is that as long as you add patches during the RC phase (which is more or less unavoidable if the schedule is to be kept), the state of the release branch can only profit from more eyes.
There's even some helpful people on #python-dev (like Arfrever from Gentoo) who frequently do post-push reviews, catching embarrassing bugs before they can sneak their way into a release (thank you Arfrever!).
OK, that's my reasoning, I'm going to fucking shut up now.
Georg
On 20 Feb 2014 04:18, "Georg Brandl" g.brandl@gmx.net wrote:
Am 19.02.2014 19:00, schrieb Georg Brandl:
Am 19.02.2014 16:50, schrieb Guido van Rossum:
On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl <g.brandl@gmx.net mailto:g.brandl@gmx.net> wrote:
Am 19.02.2014 00:54, schrieb Barry Warsaw: > On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: > >>Am 17.02.2014 00:25, schrieb Larry Hastings: >>> And my local branch will remain private until 3.4.0 final
ships!
>> >>sorry, but this is so wrong. Is there *any* reason why to keep
this branch
>>private? > > IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or
paranoia.
And it is very understandable that vendors (or even "just" our
binary
building experts) want to make as many tests with what will be RC2
and
then final as they can, to catch possible issues before release.That's why it's RC2 and not 3.4final, right? Once Larry says it's
baked,
everyone *will* have a chance to test it. What value is a preview of
the preview
really going to add?
Ned told me just a few days ago that he does regular pre-tag builds of
the OSX
installers, and as for the Debian/Ubuntu side Barry can say more. The
thing
with the RCs is that as long as you add patches during the RC phase
(which is
more or less unavoidable if the schedule is to be kept), the state of
the
release branch can only profit from more eyes.
There's even some helpful people on #python-dev (like Arfrever from
Gentoo) who
frequently do post-push reviews, catching embarrassing bugs before they
can
sneak their way into a release (thank you Arfrever!).
OK, that's my reasoning, I'm going to fucking shut up now.
I suspect everyone is also highly aware of the fact that there are some ambitious changes in 3.4, the release of rc1 is bringing the usual wave of additional third party testing that has picked up some interesting regressions and usability issues (e.g. the Alembic test suite found a fun one in the inspect module, while the pip installation doesn't currently play nice with UAC on Windows), and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc.
That brings with it a strong desire to parallelise things as much as possible, and read only access to the upcoming release helps greatly in knowing which regressions have already been addressed, allowing third party testers to more easily focus on any remaining issues.
A "user beware, this may be rebased without warning" clone would be fine for that purpose, and I suspect in most cases just running rc2 -> final with such a clone available (preserving Larry's current workflow until rc2) would be sufficient to address most concerns.
Regards, Nick.
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/ncoghlan%40gmail.com
Nick Coghlan writes:
I suspect everyone is also highly aware of the fact that there are some ambitious changes in 3.4,
Which is an argument for longer beta and RC periods than usual, or maybe some of the ambition should have been restrained. It's not necessarily a reason why more eyes help (see below).
the release of rc1 is bringing the usual wave of additional third party testing that has picked up some interesting regressions and usability issues (e.g. the Alembic test suite found a fun one in the inspect module, while the pip installation doesn't currently play nice with UAC on Windows), and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc.
OK, but that means we're screwed regardless. We've decided to release what we've got on a specific timeline, and a few extra days of testing is going to make a marginal difference on average.
Remember that under time pressure in bugfixing, the average programmer introduces a new bug that gets through to a product every ten lines. OK, so we're[1] 100X better than average, and I suppose for some subset 1000X better. Still that means several new bugs, and some of them may be doozies.
That brings with it a strong desire to parallelise things as much as possible, and read only access to the upcoming release helps greatly in knowing which regressions have already been addressed, allowing third party testers to more easily focus on any remaining issues.
Sure, but it *doesn't* help in knowing which ones are *correctly* addressed. These *are* ambitious changes; some of the remaining bugs may be very deep. The obvious fixes may do more harm than good. Ie, "more eyes" is (a) mostly a fallacy (as Heinlein put it, the wisdom of a group is less than or equal to the maximum of the wisdom of the members) and (b) in any case the "more eyes" effect is diluted if people are deliberately looking at different parts of the code.
A "user beware, this may be rebased without warning" clone would be fine for that purpose, and I suspect in most cases just running rc2 -> final with such a clone available (preserving Larry's current workflow until rc2) would be sufficient to address most concerns.
Larry's already providing tarballs as I understand it.
The argument that a "read-only, no cherrypicking by committers" repo is nothing but a better tarball is valid, but as I say, AFAICS the expected gain is pretty marginal. The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process?
Footnotes: [1] FVO "we" not containing "me". You'll notice I'm not submitting patches.<wink/>
On Feb 20, 2014, at 10:24 AM, Stephen J. Turnbull wrote:
But should Ubuntu desires be distorting a volunteer RE's process?
Ubuntu 14.04 final freeze is April 10[1], so I think that's the drop dead date for getting 3.4 final into Ubuntu 14.04. Matthias may correct me, but I think if we can hit that date (well, maybe a day or two early to be safe) we're good.
Missing that date probably isn't catastrophic, especially if there are few to no changes between the last Python 3.4 rc before our final freeze, and Python 3.4 final. What it means is that 14.04 won't ship with the final Python 3.4 and we'll have to do a "stable release update" after 14.04 to catch up to the Python 3.4 final release. It does mean that many Ubuntu users won't see it until 14.04.1, whenever that is, if at all. But if the only difference is a version string and sys.version_info, then I don't think that's so bad. And ultimately we'll have to do that anyway to get the LTS users Python 3.4.1, 3.4.2, and so on.
Two notes: Matthias just enabled Python 3.4 as the default Python 3, and there's no going back. Also, we have aligned the Python release schedules with external schedules before, most notably Apple a couple of times. I think it's reasonable to do so *if* we can do it without sacrificing the quality of Python 3.4's final release.
Cheers, -Barry
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote:
The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process?
When talk of slipping the final date again was discussed, Guido basically said no.
-- ~Ethan~
On 20 Feb 2014 12:26, "Ethan Furman" ethan@stoneleaf.us wrote:
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote:
The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process?
When talk of slipping the final date again was discussed, Guido basically
said no.
Guido said no more to the additional Argument Clinic related changes, rather than to an extra rc in general.
Note that I made my comment before Larry pointed out the existing schedule was a week longer than I thought, and Barry clarified that there *is* still room for a third rc if Larry decides that would be appropriate.
Cheers, Nick.
-- ~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/ncoghlan%40gmail.com
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote:
Nick Coghlan writes:
A "user beware, this may be rebased without warning" clone would be fine for that purpose, and I suspect in most cases just running rc2 -> final with such a clone available (preserving Larry's current workflow until rc2) would be sufficient to address most concerns.
Larry's already providing tarballs as I understand it.
Yep. Well, just "tarball" so far ;-)
As for a "user beware" clone: I worry about providing anything that looks/tastes/smells like a repo. Someone could still inadvertently push those revisions back to trunk, and then we'd have a real mess on our hands. Publishing tarballs drops the possibility down to about zero.
The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process?
I haven't seen anything that makes me think we're in trouble. Every release has its bumps; that's what the rc period is for. I remind you we're still a month away.
I grant you asyncio is still evolving surprisingly rapidly for an rc. But it doesn't have an installed base yet, and it's provisional anyway, so it's not making me anxious.
Worst case, we issue a 3.4.1 on a very accelerated schedule. But it doesn't seem like it'll be necessary.
//arry/
Larry Hastings writes:
Someone could still inadvertently push those revisions back to trunk, and then we'd have a real mess on our hands. Publishing tarballs drops the possibility down to about zero.
Note: I see no reason for you to change your process for the 3.4.0 release. I just want to record my comments in this thread for future reference.
I don't think any of the above is true. First, although "possibility of inadvertant push" as written is obviously correct, I don't think the implication that the *probability* of an *inadvertant* push is any higher is correct (somebody else -- Antoine? Guido? -- already pointed this out). The reasoning is that if somebody clones from a mirror of your release branch, they will have to make a deliberate decision to push to trunk, or a deliberate decision to merge or cherrypick from your branch into a branch destined for trunk, to cause a problem. That's actually safer than if they apply a patch from the tracker by hand, since in the case of a patch there will be no metadata to indicate that the conflict was caused by concurrent cherrypicks, and if they're sufficiently incautious, the actual change data may be different. That is messy.
Second, what "real mess"? "VCS means never having to say 'Oh, shit!'" If such a thing happens, you just take your branch, do an "ours" merge with trunk obsoleting the trunk, and then cherrypick everything appropriate from obs-trunk. Tedious, yes. Somewhat error-prone, I suppose. Keep the buildbots very busy for a while, for sure. Real mess? IMHO, no. The fact that the repair procedure uses only "proper merges" (vs. rebase) means that rebase confusion can't propagate silently, nor can committed changes (in anybody's branch) be inadvertantly lost. (There are better strategies than the above, which I'll be happy to discuss if and when necessary. And for tedium reduction, there are features like git's filter-branch, which a Mercurial dev assures me can be done with hg too.)
Third, tarballs don't drop the possibility to zero. We know that patch reviewers have those patches in local workspaces. In some cases you can diff a file from the tarball and get the patch you want (mostly, as mentioned above) and apply that to your feature branch. In the case of asyncio, some such path to a duplicate cherrypick seems quite probable (compared with "near zero", anyway).
I haven't seen anything that makes me think we're in trouble.
Your evaluation is plenty good enough for me. But the actual information that your assessment is based on is almost private to you, and that's the reason other folks want access to a repo. By "almost private" I mean that the manipulation of revision information that DVCSes make so convenient is unavailable to them.
On Wed, 19 Feb 2014 19:20:12 -0800 Larry Hastings larry@hastings.org wrote:
As for a "user beware" clone: I worry about providing anything that looks/tastes/smells like a repo. Someone could still inadvertently push those revisions back to trunk, and then we'd have a real mess on our hands.
If you're using a separate named branch for your release work, then the hg.python.org hooks will forbid pushing them back to the main repo.
Regards
Antoine.
On Thu, 20 Feb 2014 10:24:16 +0900 "Stephen J. Turnbull" stephen@xemacs.org wrote:
The argument that a "read-only, no cherrypicking by committers" repo is nothing but a better tarball is valid, but as I say, AFAICS the expected gain is pretty marginal. The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule.
I don't really buy the "short time schedule" argument. The delay between 3.3 and 3.4 is ~18 months as usual.
Regards
Antoine.
Antoine Pitrou writes:
On Thu, 20 Feb 2014 10:24:16 +0900 "Stephen J. Turnbull" stephen@xemacs.org wrote:
The argument that a "read-only, no cherrypicking by committers" repo is nothing but a better tarball is valid, but as I say, AFAICS the expected gain is pretty marginal. The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule.
I don't really buy the "short time schedule" argument. The delay between 3.3 and 3.4 is ~18 months as usual.
"Short" here isn't relative to calendar time nor to the development cycle length. It's relative to the time needed to properly beta and RC an "ambitious" set of changes, with more than the usual number of patches during RC AFAIK, and the time allowed for that testing. I'm not saying it isn't enough time, but I certainly think that more time or a less ambitious release would make folks feel more comfortable, and less apt to suggest changes in a release process at this late date.
My point is that I don't think that changing Larry's process would make a big difference to our ability to test the release candidates, Ubuntu deadlines not withstanding.
Am 20.02.2014 02:24, schrieb Stephen J. Turnbull: [ ... ]
Sure, but it *doesn't* help in knowing which ones are *correctly* addressed. These *are* ambitious changes; some of the remaining bugs may be very deep. The obvious fixes may do more harm than good. Ie, "more eyes" is (a) mostly a fallacy (as Heinlein put it, the wisdom of a group is less than or equal to the maximum of the wisdom of the members) and (b) in any case the "more eyes" effect is diluted if people are deliberately looking at different parts of the code.
All depends from the way, a group is organized, composed etc. What might stiffle results in a group for example is hierarchy, resp. a fear to get chastised by the leader.
After all I'm not in position to make a guess here - but rather would expect much higher results by groups-coop than from most gifted single person among.
Am 19.02.2014 22:18, schrieb Nick Coghlan:
and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc.
well, I think it would be wrong to restrict that for only that reason. I did object to delay the release cycle a second time for completing a feature. If the release has to be delayed for QA reasons, that's a good reason. Having a Debian background myself ;)
I'm fine to ship with a rc3 too, and update it post-release, after wading through distribution bureaucracy ... but please don't use this as an example of a distribution influencing an upstream. There are "better" examples for this :-/
Matthias
On 21 Feb 2014 08:38, "Matthias Klose" doko@ubuntu.com wrote:
Am 19.02.2014 22:18, schrieb Nick Coghlan:
and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc.
well, I think it would be wrong to restrict that for only that reason. I
did
object to delay the release cycle a second time for completing a feature.
If
the release has to be delayed for QA reasons, that's a good reason.
Having a
Debian background myself ;)
I'm fine to ship with a rc3 too, and update it post-release, after wading through distribution bureaucracy ... but please don't use this as an
example of
a distribution influencing an upstream. There are "better" examples for
this :-/
Thanks for the clarification. That said, supporting someone else's external deadline can definitely help with resisting the urge to allow "just one more little adjustment" :)
Cheers, 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
On Tue, 18 Feb 2014 18:54:23 -0500 Barry Warsaw barry@python.org wrote:
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch private?
IMO, no. read-only for !larry sure, but not private.
Agreed too. Python isn't developed in private.
Regards
Antoine.
On Wed, Feb 19, 2014 at 4:13 AM, Antoine Pitrou solipsis@pitrou.net wrote:
Agreed too. Python isn't developed in private.
That's a ridiculous accusation, bordering on malicious. Larry isn't "developing Python in private". He is simply working on something that he'll release when he feels comfortable releasing it.
I don't think I understand the concern. Why is this different from any other mistake someone may make when pushing code?
Maybe because 1000s of people are apparently ready to micro-manage and criticize Larry's work and waiting for him to screw up? Why are you trying to tell Larry how to use his tools? Larry *volunteered* to be the release manager and got widespread support when he did. If you don't trust him, go fucking fork the release yourself.
Also "rebase" is only really ok on private repos, as soon as something is published you should use "merge".
And that's exactly why Larry is holding off pushing.
2014-02-17 0:25 GMT+01:00 Larry Hastings larry@hastings.org:
You might think that anything you check in to the "default" branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to "default" between my last revision for "rc1" (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships!
I'm a little bit lost with the Misc/NEWS file. The current title is still "What's New in Python 3.4.0 release candidate 2?". Should we start a new "Python 3.4.1" section?
Victor
-
Andreas Röhler -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Ethan Furman -
Georg Brandl -
Gregory P. Smith -
Guido van Rossum -
Hrvoje Niksic -
Larry Hastings -
Matthias Klose -
Nick Coghlan -
Paul Moore -
Ryan Gonzalez -
Stephen J. Turnbull -
Terry Reedy -
Victor Stinner