Reminder: Python 3.4 alpha 1 release is Saturday August 3
It's about nine days from now. I expect to tag the release late next week. So if you're doing any major brain surgery, please finish it up in the next week or so.
Your mildly anxious release manager,
//arry/
p.s. Anybody have contact information for Jim Hugunin? He left Google back in May and has dropped off the face of the internet. I want to interview him for my podcast.
Hi,
Le jeudi 25 juillet 2013 à 13:07 -0700, Larry Hastings a écrit :
It's about nine days from now. I expect to tag the release late next week. So if you're doing any major brain surgery, please finish it up in the next week or so.
Once http://bugs.python.org/issue18112 is reviewed, the PEP 442 implementation could go in.
cheers
Antoine.
Your mildly anxious release manager,
/arry
p.s. Anybody have contact information for Jim Hugunin? He left Google back in May and has dropped off the face of the internet. I want to interview him for my podcast.
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
On Thu, 25 Jul 2013 13:07:59 -0700, Larry Hastings larry@hastings.org wrote:
It's about nine days from now. I expect to tag the release late next week. So if you're doing any major brain surgery, please finish it up in the next week or so.
FYI I'm planning on working on some non-trivial stuff for the email package in August, but it will all go in the "provisional" part of the library, which will stay provisional for 3.4. As with the existing provisional code, it will involve moving some bits of code from the existing classes into policy hooks on the backward compatibility policy, and then implementing new features using those same hooks on the provisional policies. I don't expect there to be any instability (that is not some trivial mistake) in the non-provisional code, as the changes there will be pretty small, and the email package has fairly extensive tests.
Nothing will land before the Alpha 1 date, and everything should (I hope!) land before Alpha 2.
--David
On 07/25/2013 01:07 PM, Larry Hastings wrote:
It's about nine days from now. I expect to tag the release late next week. So if you're doing any major brain surgery, please finish it up in the next week or so.
Do modifications to _json to support Enum count as major? If they don't make it in to the first alpha, can I put them in the second?
similarly-anxious-newbie-committer-ly yours,
~Ethan~
On 07/30/2013 01:01 PM, Ethan Furman wrote:
Do modifications to _json to support Enum count as major? If they don't make it in to the first alpha, can I put them in the second?
You can put them in either.
//arry/
2013/7/25 Larry Hastings larry@hastings.org:
It's about nine days from now. I expect to tag the release late next week. So if you're doing any major brain surgery, please finish it up in the next week or so.
I hope that I would have enough free time before the alpĥa2 to:
- find a consensus on the file descriptor inheritance (!), finish "the" PEP and the implementation
- write a new module (!) using the PEP 445 (malloc hooks) to inject memory allocation failures and track memory allocations
(It is maybe already too late !)
I also hope that the assertions that I added in the issue #18408 would not break too much applications (when using Python 3.4 compiled in debug mode) :-) I added assertions to ensure that a Python function is not called when an exception is set. The problem is that a Python function can clear or replace the current exception. For example, hasattr(obj, name) replaces the current exception, and later clears the new exceptions, if the attribute does not exist. It doesn't care if it was called with an exception already set (PyErr_Occurred() is not NULL).
I fixed all issues related to these assertions in the Python stdlib, but I don't know if it breaks third party code. In my opinion, if these assertions fail, there is a bug that must be fixed.
Tell me if it's better to discuss these points on python-dev ;-)
Victor
2013/8/2 Victor Stinner victor.stinner@gmail.com:
2013/7/25 Larry Hastings larry@hastings.org:
It's about nine days from now. I expect to tag the release late next week. So if you're doing any major brain surgery, please finish it up in the next week or so.
I hope that I would have enough free time before the alpĥa2 to:
- find a consensus on the file descriptor inheritance (!), finish "the" PEP and the implementation
- write a new module (!) using the PEP 445 (malloc hooks) to inject memory allocation failures and track memory allocations
(It is maybe already too late !)
Oops, I mean before the first beta. I didn't see that there are 4 alpha versions scheduled.
Is it ok to do such changes between the alpha4 and beta1?
Victor
On 08/01/2013 04:14 PM, Victor Stinner wrote:
Is it ok to do such changes between the alpha4 and beta1?
Yes. We don't hit feature-freeze until beta 1.
But it's best to get your changes in earlier, so they can be in one (or more) alphas. And in case you discover something wrong with your approach and you need to make breaking changes, those should definitely be in the alphas. And bigger changes should be earlier than smaller changes, if you can approach the problem that way.
But you've got time.
By the way, it looks like 3.4a1 will be basically on time. I've triaged all the extant release blockers, so I don't have any right now. (Mostly just marking them as "deferred blocker"...) I plan to tag today for a release tomorrow.
//arry/
In article 51FC0BD9.1000404@hastings.org, Larry Hastings larry@hastings.org wrote:
By the way, it looks like 3.4a1 will be basically on time. I've triaged all the extant release blockers, so I don't have any right now. (Mostly just marking them as "deferred blocker"...) I plan to tag today for a release tomorrow.
Hmm. I understand this is an alpha but I was hoping to get a few more fixes in today. Perhaps, in the future, we can be more clear about exactly when the code freeze time (tag time) is vs a release time. From a developer point of view, the former is important, the latter much less so. From a release team point of view, both are.
-- Ned Deily, nad@acm.org
On 08/02/2013 01:00 PM, Ned Deily wrote:
Hmm. I understand this is an alpha but I was hoping to get a few more fixes in today. Perhaps, in the future, we can be more clear about exactly when the code freeze time (tag time) is vs a release time. From a developer point of view, the former is important, the latter much less so. From a release team point of view, both are.
From PEP 101, "Doing Python Releases 101":
IT IS HIGHLY RECOMMENDED THAT YOU AT LEAST TAG THE TREE 24 HOURS BEFORE A FINAL RELEASE. This will give the Experts enough time to do their bits before the announcement goes out. The schedule calls for the Alpha 1 release tomorrow. Ergo, tag today.
Should I add "expected tag dates" to the schedule?
I can immediately grant you a small delay if that's all you need; how about I try to tag around midnight (PST). If you need longer than that let's discuss it in public here.
By the way, folks, I'm delaying Alpha 2 on behalf of Martin (who will be on vacation on the old date). The new release date for Alpha 2 will be Sunday September 8, therefore tagging on Saturday September 7. I don't currently plan on slipping Alpha 3 or any subsequent releases as a result. I'll update the release schedule PEP once Alpha 1 is out.
But speaking of adjusting the schedule, I'm also considering changing bumping all the remaining release dates forward by a day. Currently all the releases are on Saturdays, which means we always tag on Friday. Ned Deily suggests instead we tag on Saturdays and release on Sundays. His reasoning: people with last-minute changes they're trying to get in are more likely to have time for Python core hacking on a Saturday than a Friday. Any opinions?
//arry/
On 08/02/2013 01:25 PM, Larry Hastings wrote:
But speaking of adjusting the schedule, I'm also considering changing bumping all the remaining release dates forward by a day. Currently all the releases are on Saturdays, which means we always tag on Friday. Ned Deily suggests instead we tag on Saturdays and release on Sundays. His reasoning: people with last-minute changes they're trying to get in are more likely to have time for Python core hacking on a Saturday than a Friday. Any opinions?
Late Saturday tagging sounds good to me. :)
-- ~Ethan~
On Fri, Aug 2, 2013 at 4:25 PM, Larry Hastings larry@hastings.org wrote:
From PEP 101, "Doing Python Releases 101":
IT IS HIGHLY RECOMMENDED THAT YOU AT LEAST TAG THE TREE 24 HOURS BEFORE A FINAL RELEASE. This will give the Experts enough time to do their bits before the announcement goes out.
The schedule calls for the Alpha 1 release tomorrow. Ergo, tag today.
When I read this, I expect it to only apply to X.Y.Z releases, not alphas and betas.
Which doesn't mean there should be an interval between the tagging and the release. (I expect a period this size for the first beta is just as valuable, since that's the API freeze.)
For anything else, I think it's up to the release manager.
Should I add "expected tag dates" to the schedule?
That, or some text explaining what to expect, would be good to have.
-Fred
-- Fred L. Drake, Jr. <fred at fdrake.net> "A storm broke loose in my mind." --Albert Einstein
In article 51FC15C2.9040708@hastings.org, Larry Hastings larry@hastings.org wrote:
From PEP 101, "Doing Python Releases 101":
IT IS HIGHLY RECOMMENDED THAT YOU AT LEAST TAG THE TREE 24 HOURS BEFORE A FINAL RELEASE. This will give the Experts enough time to do their bits before the announcement goes out. The schedule calls for the Alpha 1 release tomorrow. Ergo, tag today.
Should I add "expected tag dates" to the schedule?
+1, or at least an approximate delta for developers
I can immediately grant you a small delay if that's all you need; how about I try to tag around midnight (PST). If you need longer than that let's discuss it in public here.
That would be nice, thanks. At this point, I'm running another set of builds and installs to double-check what's in now. That's a bit more important since we're down to only one OS X buildbot at the moment and that one runs an old version of OS X (10.4 Tiger) that we don't produce installers for anymore for 3.3+. While it is possible to patch the installer builds, I really really try to avoid that.
But speaking of adjusting the schedule, I'm also considering changing bumping all the remaining release dates forward by a day. Currently all the releases are on Saturdays, which means we always tag on Friday. Ned Deily suggests instead we tag on Saturdays and release on Sundays. His reasoning: people with last-minute changes they're trying to get in are more likely to have time for Python core hacking on a Saturday than a Friday. Any opinions?
Looking back over the past few years, I believe most releases have been tagged sometime on Saturday, generally late on Saturday. Whatever time is decided on by the release manager, I think it would be useful to make developers aware of that ahead of time. Perhaps Benjamin or Georg have opinions from recent previous releases.
Thanks for being our release manager, Larry!
-- Ned Deily, nad@acm.org
Le vendredi 02 août 2013 à 13:25 -0700, Larry Hastings a écrit :
From PEP 101, "Doing Python Releases 101":
IT IS HIGHLY RECOMMENDED THAT YOU AT LEAST TAG THE TREE 24 HOURS BEFORE A FINAL RELEASE. This will give the Experts enough time to do their bits before the announcement goes out. The schedule calls for the Alpha 1 release tomorrow. Ergo, tag today.
Should I add "expected tag dates" to the schedule?
No need to IMO, but you mention it when sending your reminder message. (most core developers certainly spare themselves the hassle of reading PEP 101 - or, once they've read it, they forget it as quickly as possible :-))
But speaking of adjusting the schedule, I'm also considering changing bumping all the remaining release dates forward by a day.
"Forward" means what? Earlier or later? (intuitively, I'd say "earlier", but that doesn't seem very consistent with your explanations)
Regards
Antoine.
On Aug 02, 2013, at 11:00 PM, Antoine Pitrou wrote:
No need to IMO, but you mention it when sending your reminder message. (most core developers certainly spare themselves the hassle of reading PEP 101 - or, once they've read it, they forget it as quickly as possible :-))
FWIW, I've always considered PEP 101 a checklist of things the RM has to do when making a release. That's the way I originally wrote and used it, and for me, with just one more release ahead of me (and a source-only one at that) for the foreseeable future, it's worked moderately well.
So IMHO, now that Larry is taking over, my suggestion is for him to view PEP 101 as the collective "wisdom" of those RMs who have gone before him. But he should feel free to make the document more useful for him, of course in consultation with the other active RMs. I certainly have no problem with each RM putting their stamp on the document, including adding their names to the Author field.
(Same general principle as with the release.py script too.)
-Barry
On 08/02/2013 02:00 PM, Antoine Pitrou wrote:
"Forward" means what? Earlier or later? (intuitively, I'd say "earlier", but that doesn't seem very consistent with your explanations)
Your intuition is the opposite of mine. When I move dates "forward", I increase the date / number / etc. So I would move forward from Saturday to the next day, Sunday.
//arry/
On 3 Aug 2013 10:25, "Larry Hastings" larry@hastings.org wrote:
On 08/02/2013 02:00 PM, Antoine Pitrou wrote:
"Forward" means what? Earlier or later? (intuitively, I'd say "earlier", but that doesn't seem very consistent with your explanations)
Your intuition is the opposite of mine. When I move dates "forward", I
increase the date / number / etc. So I would move forward from Saturday to the next day, Sunday.
Heh, I'm with Antoine in using "forward/backward" in the sense of "bring closer/move further away", and hence "earlier/later", when it comes to dates in the future.
Yay, English! How on Earth do we ever get anything done in this ridiculous language? :)
Cheers, Nick.
/arry
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
On Fri, Aug 2, 2013 at 8:13 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On 3 Aug 2013 10:25, "Larry Hastings" larry@hastings.org wrote:
On 08/02/2013 02:00 PM, Antoine Pitrou wrote:
"Forward" means what? Earlier or later? (intuitively, I'd say "earlier", but that doesn't seem very consistent with your explanations)
Your intuition is the opposite of mine. When I move dates "forward", I increase the date / number / etc. So I would move forward from Saturday to the next day, Sunday.
Heh, I'm with Antoine in using "forward/backward" in the sense of "bring closer/move further away", and hence "earlier/later", when it comes to dates in the future.
Yay, English! How on Earth do we ever get anything done in this ridiculous language? :)
Moving, or "pushing" dates back definitely means "later", at least in my head. Some formal sources agree. For example, http://www.macmillandictionary.com/us/dictionary/american/push-back:
push back: to arrange a later time for something
Eli
Quoting Fred Drake fred@fdrake.net:
IT IS HIGHLY RECOMMENDED THAT YOU AT LEAST TAG THE TREE 24 HOURS BEFORE A FINAL RELEASE. This will give the Experts enough time to do their bits before the announcement goes out.
The schedule calls for the Alpha 1 release tomorrow. Ergo, tag today.
When I read this, I expect it to only apply to X.Y.Z releases, not alphas and betas.
No, it actually should apply to all releases (alpha and beta as well).
The 24h delay comes from the desire to release binaries. Due to time zones and work distribution across people, several hours can easily pass, and 24h is not at all unrealistic.
That, or some text explaining what to expect, would be good to have.
It's easy enough: the tag is likely to occur 24h before the scheduled release.
Regards, Martin
participants (11)
-
Antoine Pitrou -
Barry Warsaw -
Eli Bendersky -
Ethan Furman -
Fred Drake -
Larry Hastings -
martin＠v.loewis.de -
Ned Deily -
Nick Coghlan -
R. David Murray -
Victor Stinner