-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Over the next several hours I will be cutting Python 2.6. All lights
and buildbots are go for final release tonight.
I have not yet heard from Trent about press releases, so we'll have to
do those after the fact.
I am also planning on releasing 3.0rc2 tonight, but only if there's
time. Final releases have much more work and the process is much less
tested, so it may take me quite a while to get 2.6 final out.
The trunk and 3.0 branches are officially frozen until further
notice. You /must/ contact me on irc if you need to make any changes.
Remember: #python-dev on irc.freenode.net. Please include my nick
'barry' in any ping so I will notice.
Yee haw!
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOPRTnEjvBPtnXfVAQIYtAP+JwBnMBLfUqlLbhuy/4QG+nr9fYvDnrp8 /WUHHleUw3uyYsBpxBlJNkmXkA52pPrvLJ7gopUCTuXiWyUZIb+dtczPc/vvZTuV qw+J1+GRmkMgc/5T5RoEF6rHAUccF7R7llZilsnttBi0TTSrw+fooDJSuqoxqd9k sMdOlOFMATg= =HqDw -----END PGP SIGNATURE-----
On Wed, Oct 1, 2008 at 12:36 PM, Barry Warsaw <barry@python.org> wrote:
Over the next several hours I will be cutting Python 2.6. All lights and buildbots are go for final release tonight.
I have not yet heard from Trent about press releases, so we'll have to do those after the fact.
Press releases can lag behind, but I hope that this time the Windows and OSX installers will be released together with the main tarball.
I am also planning on releasing 3.0rc2 tonight, but only if there's time.
I'd recommend against this now. We need a few more days to implement the solution for undecodable filenames. There's a patch set by Victor Stinner that does most of what I'd like to have, but it needs 1-2 more rounds of review and refinements. I'd really like to hold up rc2 until this is in.
Final releases have much more work and the process is much less tested, so it may take me quite a while to get 2.6 final out.
The trunk and 3.0 branches are officially frozen until further notice. You /must/ contact me on irc if you need to make any changes.
Why freeze the 3.0 branch?
Remember: #python-dev on irc.freenode.net. Please include my nick 'barry' in any ping so I will notice.
Yee haw!
Amen! Thanks for your relentless efforts, Barry and others!!!
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, Oct 1, 2008 at 3:33 PM, Guido van Rossum <guido@python.org> wrote:
On Wed, Oct 1, 2008 at 12:36 PM, Barry Warsaw <barry@python.org> wrote:
The trunk and 3.0 branches are officially frozen until further notice. You /must/ contact me on irc if you need to make any changes.
Why freeze the 3.0 branch?
So he can release 3.0rc2, I imagine.
-- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 1, 2008, at 4:33 PM, Guido van Rossum wrote:
On Wed, Oct 1, 2008 at 12:36 PM, Barry Warsaw <barry@python.org>
wrote:Over the next several hours I will be cutting Python 2.6. All
lights and buildbots are go for final release tonight.I have not yet heard from Trent about press releases, so we'll have
to do those after the fact.Press releases can lag behind, but I hope that this time the Windows and OSX installers will be released together with the main tarball.
I agree, but I have not heard from Ronald or Martin about that yet.
Ronald, are you still planning on building the OS X installer? I
believe we also want Sean to build the RPMs.
Here's what might work: I will build the source tarball as normal,
uploading everything to dinsdale. I'll fiddle the web site locally
but not commit the changes, so they won't become public yet. I'll
send a message here when everything's ready and then if we hear from
Ronald and Martin, they can build the binaries. As long as it's
October 1st somewhere in the world, we won't be lying. :)
If I don't hear from them though, I will push the big red button just
before midnight my time (US/Eastern, UTC-0400). We'll have to back-
load the binaries tomorrow.
I am also planning on releasing 3.0rc2 tonight, but only if there's
time.I'd recommend against this now. We need a few more days to implement the solution for undecodable filenames. There's a patch set by Victor Stinner that does most of what I'd like to have, but it needs 1-2 more rounds of review and refinements. I'd really like to hold up rc2 until this is in.
Great, works for me!
Final releases have much more work and the process is much less
tested, so it may take me quite a while to get 2.6 final out.The trunk and 3.0 branches are officially frozen until further
notice. You /must/ contact me on irc if you need to make any changes.Why freeze the 3.0 branch?
It's not now <wink>. So we'll put off 3.0rc2 and leave the 3.0 branch
thawed.
Remember: #python-dev on irc.freenode.net. Please include my nick
'barry' in any ping so I will notice.Yee haw!
Amen! Thanks for your relentless efforts, Barry and others!!!
i-can-has-vacation-now?-ly y'rs,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOPiNHEjvBPtnXfVAQIhmQP+KVFqOe0y2+bfhVWmLkoqhUTPrFxrnP6F Zt2RzQHsklLdkRZayXCA2UqWSMp8YblZIxcp5n/UFRMnmIXOR6RzeAfGuZNboSd+ 4pVdIVh6ALvclIQvlqKyabfa4IA2rzP/zcDRUFBLatqCnJ7+oKymNeYAuV6mFW8Q wtZnWNY+oZg= =E9xu -----END PGP SIGNATURE-----
Press releases can lag behind, but I hope that this time the Windows and OSX installers will be released together with the main tarball.
I agree, but I have not heard from Ronald or Martin about that yet.
That's because you didn't ask, I guess.
Ronald, are you still planning on building the OS X installer? I believe we also want Sean to build the RPMs.
Here's what might work: I will build the source tarball as normal, uploading everything to dinsdale. I'll fiddle the web site locally but not commit the changes, so they won't become public yet. I'll send a message here when everything's ready and then if we hear from Ronald and Martin, they can build the binaries. As long as it's October 1st somewhere in the world, we won't be lying. :)
If I don't hear from them though, I will push the big red button just before midnight my time (US/Eastern, UTC-0400). We'll have to back-load the binaries tomorrow.
I certainly won't be able to produce binaries before 8:00 UTC, October 2. I'll be asleep for the coming hours, then commute, etc.
I must admit that I'm fairly unhappy how coordination with other people works when creating releases. Anthony Baxter did a better job. This started by asking whether the people involved have actually time to work on the release, at the day in question.
Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 1, 2008, at 5:00 PM, Martin v. Löwis wrote:
Press releases can lag behind, but I hope that this time the Windows and OSX installers will be released together with the main tarball.
I agree, but I have not heard from Ronald or Martin about that yet.
That's because you didn't ask, I guess.
Probably so, though today's release has been advertised for months.
Ronald, are you still planning on building the OS X installer? I believe we also want Sean to build the RPMs.
Here's what might work: I will build the source tarball as normal, uploading everything to dinsdale. I'll fiddle the web site locally
but not commit the changes, so they won't become public yet. I'll send a message here when everything's ready and then if we hear from
Ronald and Martin, they can build the binaries. As long as it's October 1st somewhere in the world, we won't be lying. :)If I don't hear from them though, I will push the big red button just before midnight my time (US/Eastern, UTC-0400). We'll have to back- load the binaries tomorrow.
I certainly won't be able to produce binaries before 8:00 UTC, October 2. I'll be asleep for the coming hours, then commute, etc.
I must admit that I'm fairly unhappy how coordination with other
people works when creating releases. Anthony Baxter did a better job. This started by asking whether the people involved have actually time to work on the release, at the day in question.
Yes, I should have been more proactive in getting everyone
coordinated, but as I say we've all known about today's release date
for a very long time. I accept responsibility though. I know I suck
and will happily resign if another sucke^H^H^H^H^Hvolunteer wants to
step up for next time :).
We'll just have to get the additional binaries when they're
available. Benjamin can do the OS X releases if necessary.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOPnaXEjvBPtnXfVAQJmUQP9HoAHtIfphjp1jwBOGXX4eKrUau5ooJWN GYl1bHguQ+dByFC/n5rXKhJR7mwfx5OkgdUiBPs5kvTZD1aVv7wD79RzZVHR5LH2 vUleHDK6iHVrJ3V/xujHlIYvEvIE15Tjhhlqz4QihJ7P0yYoUGLmXp4h74Uv91Rh POmd2ozlhtE= =0F3r -----END PGP SIGNATURE-----
Yes, I should have been more proactive in getting everyone coordinated, but as I say we've all known about today's release date for a very long time.
Sure. However, creating the tag around 22:00 UTC (or later) makes it fairly difficult for me to create binaries on the same day. To have binaries released on the scheduled day, the tag should be available no later than 16:00 UTC (which still means that I'll have to stay in office longer than usual).
Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 1, 2008, at 5:19 PM, Martin v. Löwis wrote:
Yes, I should have been more proactive in getting everyone
coordinated, but as I say we've all known about today's release date for a very
long time.Sure. However, creating the tag around 22:00 UTC (or later) makes it fairly difficult for me to create binaries on the same day. To have binaries released on the scheduled day, the tag should be available no later than 16:00 UTC (which still means that I'll have to stay in office longer than usual).
Yes, of course that makes sense. What would be a better time for you
Martin? I would like to at least debug this aspect of the PEP so that
next time we can coordinate better.
I'm guessing the earlier in your day the better. I'm generally online
by 1300 UTC. Maybe it makes sense to do the prep work the night
before so the tag is ready by your morning?
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOPp9nEjvBPtnXfVAQIipwQAjNywHldquD5henfI8lDNKyiX/TxZ41Sz GJGQJQMIJe8oM8OWDg387+DGgjbHrmUQjQPYko54vMw4rwrJFi4xO8rpcVCZDary DR6qotfFDSRb6ObBv5GRsX6AR4uwAOjpYUAjTnsykIe4j+AYb+wECaNhR+nh8fz3 7OXowSgUFAc= =mszQ -----END PGP SIGNATURE-----
Yes, of course that makes sense. What would be a better time for you Martin? I would like to at least debug this aspect of the PEP so that next time we can coordinate better.
As I said: If you create the tag in your morning, I can do the binaries before heading home. Please send an email message to martin.vonloewis@hpi.uni-potsdam.de and martin@v.loewis.de when the tag is done (along to all other people who need to know that the tag has been created).
I'm guessing the earlier in your day the better. I'm generally online by 1300 UTC. Maybe it makes sense to do the prep work the night before so the tag is ready by your morning?
Afternoon/early evening is fine. Not sure how much time you need: if you can do it by 1600 UTC, that's good enough (I know that a release is upcoming, so I would be waiting for your message).
Of course, if you rather prefer to do that stuff in your afternoon (the day before the release): that would work for me as well. I think people will accept the tree being frozen for more than 24 hours.
Of course, Anthony is in a different time zone, so when he created the tag in his evening, I had all day, and the binaries would still be available when he got up the next morning.
Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 1, 2008, at 5:32 PM, Martin v. Löwis wrote:
Yes, of course that makes sense. What would be a better time for you Martin? I would like to at least debug this aspect of the PEP so
that next time we can coordinate better.As I said: If you create the tag in your morning, I can do the
binaries before heading home. Please send an email message to martin.vonloewis@hpi.uni-potsdam.de and martin@v.loewis.de when the
tag is done (along to all other people who need to know that the tag has been created).I'm guessing the earlier in your day the better. I'm generally
online by 1300 UTC. Maybe it makes sense to do the prep work the night
before so the tag is ready by your morning?Afternoon/early evening is fine. Not sure how much time you need: if
you can do it by 1600 UTC, that's good enough (I know that a release is upcoming, so I would be waiting for your message).Of course, if you rather prefer to do that stuff in your afternoon (the day before the release): that would work for me as well. I think people will accept the tree being frozen for more than 24 hours.
Of course, Anthony is in a different time zone, so when he created the tag in his evening, I had all day, and the binaries would still be available when he got up the next morning.
You're absolutely right and that sounds good. I will update the PEP
accordingly. Martin, Ronald, Sean, what timezones are you in? I am
US/Eastern.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOPuAnEjvBPtnXfVAQI52QQAm8HIZ6JHYgvj7yS+l1hjjqhhSgASMB93 hYp6LCDBWHs4gSrkuWn4p5FhiR0jYuW89GLkg+I19+AGbs6qgoTaw+Kcp1usXlRI mOi6V3hlQg19xT1kBFGnYHMF1ge5lsyVO7czokWOGGfJnqYbdq8LcMaBXGE8ePwt mGSeIkKRnuM= =i9y+ -----END PGP SIGNATURE-----
Martin v. Löwis wrote:
Of course, Anthony is in a different time zone, so when he created the tag in his evening, I had all day, and the binaries would still be available when he got up the next morning.
That's a good point - if Barry is on the US west coast somewhere, it actually works out to about a 17 or 18 hour time advantage for those of us in eastern Australia (depending on daylight saving).
FWIW, I'd personally be fine with the trunk being frozen a day early if it was necessary to get the tags and binaries all ready on the day of release - just so long as it was mentioned in the release PEP.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
http://www.boredomandlaziness.org-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 1, 2008, at 5:44 PM, Nick Coghlan wrote:
Martin v. Löwis wrote:
Of course, Anthony is in a different time zone, so when he created the tag in his evening, I had all day, and the binaries would still be available when he got up the next morning.
That's a good point - if Barry is on the US west coast somewhere, it actually works out to about a 17 or 18 hour time advantage for those
of us in eastern Australia (depending on daylight saving).
I'm US/Eastern, but it's not that different. :)
FWIW, I'd personally be fine with the trunk being frozen a day early
if it was necessary to get the tags and binaries all ready on the day of release - just so long as it was mentioned in the release PEP.
IIUC, the critical bottleneck is tagging the tree, so the RM needs to
make it far enough through the PEP to get to that point. Of course
that does mean freezing the tree, and I don't think it's too difficult
to do that.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOPwOnEjvBPtnXfVAQJVXQP/YP/JYd7r7KKv1mtZVFBAq9QpTCi6bLse xORM1W42aAYLwRezlmXkVLcoM7ypMk2htH+78VuMtQz6v9GPBkjaMYmwUqrH5SQO cm/mRLouZwX4hgWsATIp9SU+MAUxiKvWisyYWfQKT7uhwakf6nCSLL0Tk6QJXhro K8tIezCxrXw= =K+Ii -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The 2.6 tag has been created.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOP1eHEjvBPtnXfVAQLDagP/RrRQrSCzLGBZK06kFR46p42rFv42ixnq IRWgBWd5wRfFAivuMrkntTyTNMniH+ujTeSaJ6oplVY78RGGBmPzERI8xBhOsZj4 HYe/X51Vmjh8hTTYqs66ljV4xydAp04MDs0g81QgFNnsqac3aCwxVV8/RIrJfn0P 8YlAqREAVYo= =s35e -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote:
IIUC, the critical bottleneck is tagging the tree, so the RM needs to make it far enough through the PEP to get to that point. Of course that does mean freezing the tree, and I don't think it's too difficult to do that.
I always found strange the need to freeze the tree. When a svn tag is created, the build process should use that tag to extract the files and build the release, while the repository is being updated normally.
In fact in a *.0 release, the tag should be a branch actually.
Sure I'm missing something...
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBSOP7oJlgi5GaxT1NAQKmwQP/XTepaw9fFqf4b3VWsocvj0s4sb7THKgF cVi7Rf424YD+i7AJzMe0aFMEsrhvor1Ma/KMMXdypymxXkUapuJmLIP6R3BWZzyp sCDzRifhgHJg6LCq3TpIPvYseurUR1P0hgLZEKf5K/EAO+BJc6RIknBOgNS0RuHG SNs5cVMhe7g= =VRp9 -----END PGP SIGNATURE-----
If there's a screwup, and you need to recut the branch, you want to be sure someone else hasn't been helpful and added something else to the repo.
On Thu, Oct 2, 2008 at 9:37 AM, Jesus Cea <jcea@jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote:
IIUC, the critical bottleneck is tagging the tree, so the RM needs to make it far enough through the PEP to get to that point. Of course that does mean freezing the tree, and I don't think it's too difficult to do that.
I always found strange the need to freeze the tree. When a svn tag is created, the build process should use that tag to extract the files and build the release, while the repository is being updated normally.
In fact in a *.0 release, the tag should be a branch actually.
Sure I'm missing something...
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBSOP7oJlgi5GaxT1NAQKmwQP/XTepaw9fFqf4b3VWsocvj0s4sb7THKgF cVi7Rf424YD+i7AJzMe0aFMEsrhvor1Ma/KMMXdypymxXkUapuJmLIP6R3BWZzyp sCDzRifhgHJg6LCq3TpIPvYseurUR1P0hgLZEKf5K/EAO+BJc6RIknBOgNS0RuHG SNs5cVMhe7g= =VRp9 -----END PGP SIGNATURE-----
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
There should be a way to re-tag only the file(s) that contain the fix.
On Wed, Oct 1, 2008 at 4:00 PM, Anthony Baxter <anthonybaxter@gmail.com> wrote:
If there's a screwup, and you need to recut the branch, you want to be sure someone else hasn't been helpful and added something else to the repo.
On Thu, Oct 2, 2008 at 9:37 AM, Jesus Cea <jcea@jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote:
IIUC, the critical bottleneck is tagging the tree, so the RM needs to make it far enough through the PEP to get to that point. Of course that does mean freezing the tree, and I don't think it's too difficult to do that.
I always found strange the need to freeze the tree. When a svn tag is created, the build process should use that tag to extract the files and build the release, while the repository is being updated normally.
In fact in a *.0 release, the tag should be a branch actually.
Sure I'm missing something...
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBSOP7oJlgi5GaxT1NAQKmwQP/XTepaw9fFqf4b3VWsocvj0s4sb7THKgF cVi7Rf424YD+i7AJzMe0aFMEsrhvor1Ma/KMMXdypymxXkUapuJmLIP6R3BWZzyp sCDzRifhgHJg6LCq3TpIPvYseurUR1P0hgLZEKf5K/EAO+BJc6RIknBOgNS0RuHG SNs5cVMhe7g= =VRp9 -----END PGP SIGNATURE-----
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Sure, but that's more fiddly. From experience, when you're cutting releases, making things as simple as possible is a good thing.
On Thu, Oct 2, 2008 at 11:35 AM, Guido van Rossum <guido@python.org> wrote:
There should be a way to re-tag only the file(s) that contain the fix.
On Wed, Oct 1, 2008 at 4:00 PM, Anthony Baxter <anthonybaxter@gmail.com> wrote:
If there's a screwup, and you need to recut the branch, you want to be sure someone else hasn't been helpful and added something else to the repo.
On Thu, Oct 2, 2008 at 9:37 AM, Jesus Cea <jcea@jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote:
IIUC, the critical bottleneck is tagging the tree, so the RM needs to make it far enough through the PEP to get to that point. Of course that does mean freezing the tree, and I don't think it's too difficult to do that.
I always found strange the need to freeze the tree. When a svn tag is created, the build process should use that tag to extract the files and build the release, while the repository is being updated normally.
In fact in a *.0 release, the tag should be a branch actually.
Sure I'm missing something...
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBSOP7oJlgi5GaxT1NAQKmwQP/XTepaw9fFqf4b3VWsocvj0s4sb7THKgF cVi7Rf424YD+i7AJzMe0aFMEsrhvor1Ma/KMMXdypymxXkUapuJmLIP6R3BWZzyp sCDzRifhgHJg6LCq3TpIPvYseurUR1P0hgLZEKf5K/EAO+BJc6RIknBOgNS0RuHG SNs5cVMhe7g= =VRp9 -----END PGP SIGNATURE-----
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 1, 2008, at 9:47 PM, Anthony Baxter wrote:
Sure, but that's more fiddly. From experience, when you're cutting releases, making things as simple as possible is a good thing.
Especially when a lot of the process is scripted.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOQry3EjvBPtnXfVAQJI7wP9HOtS7jMhOX4g47PZ4mNUs6VYywBEV7uo LZo0EuqJHiWfOHjkmpAipxo2ApXhhqpvFgGNtDBx4lPnsjbJbsrg2TO2/F8fwkMA O9oR3oQ5opUD5tONwE5q/1GHJPssw+UazqPP3262+K0UFS5IqwDlDu2msx3/H+sv YaB6kAykvMA= =Z8ir -----END PGP SIGNATURE-----
That's why I wrote the welease.py script. Dunno if you've been using it. I wanted to make the release process as foolproof as possible so I wouldn't screw it up :-)
On Thu, Oct 2, 2008 at 12:02 PM, Barry Warsaw <barry@python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 1, 2008, at 9:47 PM, Anthony Baxter wrote:
Sure, but that's more fiddly. From experience, when you're cutting releases, making things as simple as possible is a good thing.
Especially when a lot of the process is scripted.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOQry3EjvBPtnXfVAQJI7wP9HOtS7jMhOX4g47PZ4mNUs6VYywBEV7uo LZo0EuqJHiWfOHjkmpAipxo2ApXhhqpvFgGNtDBx4lPnsjbJbsrg2TO2/F8fwkMA O9oR3oQ5opUD5tONwE5q/1GHJPssw+UazqPP3262+K0UFS5IqwDlDu2msx3/H+sv YaB6kAykvMA= =Z8ir -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 1, 2008, at 10:05 PM, Anthony Baxter wrote:
That's why I wrote the welease.py script. Dunno if you've been using it. I wanted to make the release process as foolproof as possible so I wouldn't screw it up :-)
Unfortunately, I had a lot of problems getting the u/i to work on my
boxes. I, with the help of Benjamin Peterson, stole lots of good
stuff from it though! We have a command line release.py script that
automates lots of it. I think the one big thing I'd like to teach it
for next time is how to fiddle all the little bits of web pages that
have to get updated. Actually building the release, along with all
the svn games and building the docs is now a pretty trivial exercise.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOQtD3EjvBPtnXfVAQIiGwQAnANc0C01gth9vSHXKnlJQcy1B21MGlCL rv/BzFuCT+H5eeI0ZZEqHioMixop1vLoA3qSNTKQl3Ry5Gmrm2Z9PYMiATp3w4K4 0oXoBPHjL49yAraHsLs8dZt04Vu+PSU9oZ7Zt9YNis39VH5GhO4gdMl6HIAwOERY yBtS9/U8TB0= =10Nt -----END PGP SIGNATURE-----
There should be a way to re-tag only the file(s) that contain the fix.
It's possible to edit the tag itself (rather than the trunk/maintenance branch), but then you also need to merge the changes back into the trunk. Also, editing the tag effectively makes it a branch; such usage is discouraged (and it will screw up conversion to, say, bazaar, which assumes a tag denotes a single revision).
It would be possible to create a branch just for the release, but that's more tedious.
In the specific case, I think it would be best to create the maintenance branch earlier; then only that branch needs to be frozen (instead of the mainline).
Regards, Martin
You're absolutely right and that sounds good. I will update the PEP accordingly. Martin, Ronald, Sean, what timezones are you in? I am US/Eastern.
I'm in CET (Central European), that GMT+2 in DST, and GMT+1 otherwise.
As for Sean: Sean and me had agreed that we won't do RPMs anymore for 2.5.x. Maybe we need to reconsider now, but my view is that binary RPMs typically fit a very specific OS release only (e.g. some version of Redhat); all the other RPM-using distributions (SuSE etc) couldn't use it. So compared to the value, the effort is too big.
Regards, Martin
On 2 Oct, 2008, at 8:08, Martin v. Löwis wrote:
You're absolutely right and that sounds good. I will update the PEP accordingly. Martin, Ronald, Sean, what timezones are you in? I am US/Eastern.
I'm in CET (Central European), that GMT+2 in DST, and GMT+1 otherwise.
I'm in CET as wel.
Ronald
On Thu, Oct 2, 2008 at 4:08 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
You're absolutely right and that sounds good. I will update the PEP accordingly. Martin, Ronald, Sean, what timezones are you in? I am US/Eastern.
I'm in CET (Central European), that GMT+2 in DST, and GMT+1 otherwise.
As for Sean: Sean and me had agreed that we won't do RPMs anymore for 2.5.x. Maybe we need to reconsider now, but my view is that binary RPMs typically fit a very specific OS release only (e.g. some version of Redhat); all the other RPM-using distributions (SuSE etc) couldn't use it. So compared to the value, the effort is too big.
+1. Last time I looked (a fair while ago now) the number of downloads of the RPM packages wasn't that large.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Anthony Baxter wrote:
If there's a screwup, and you need to recut the branch, you want to be sure someone else hasn't been helpful and added something else to the repo.
But you can put the tag/create the branch in any revision you want...
In fact, my approach would be to create a 2.6 branch after 2.6b3, and leave the trunk for 2.7 work.
No, I am not voluntering as release manager O:-). If freezing the tree 24 hours is needed, that's fine.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBSOT/Splgi5GaxT1NAQLgugQAnOkKOAs8Fy+SxoLOeBvu1cVdl4/Vhrfy UFBN8Qcmx+fuD0i9PJj6oggTJNQflA9D/AtqflRKfYvBRQWdGlG864RpCWe4f0N4 XZTx8OXzT35wp8w8x6jlx8YhWeNvESO9OCsSAyyLb8CZJuLGgtod8VkyhWgjPgXh E2GYWqApYms= =JH2/ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 2, 2008, at 2:08 AM, Martin v. Löwis wrote:
You're absolutely right and that sounds good. I will update the PEP accordingly. Martin, Ronald, Sean, what timezones are you in? I am US/Eastern.
I'm in CET (Central European), that GMT+2 in DST, and GMT+1 otherwise.
Got it, thanks.
As for Sean: Sean and me had agreed that we won't do RPMs anymore for 2.5.x. Maybe we need to reconsider now, but my view is that binary
RPMs typically fit a very specific OS release only (e.g. some version of Redhat); all the other RPM-using distributions (SuSE etc) couldn't use it. So compared to the value, the effort is too big.
Yep, Sean said he didn't have time to do the RPMs this time, and I
agree completely, the effort is too big for the value. I've nixed the
RPM steps from PEP 101.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOUPI3EjvBPtnXfVAQKrXgP/e0AD1+5aX8SsB7SOdY6s6u0pHk7MFZzl 8mblmD9dz6aa/pdQkhFNluFhIBkX76JA4mI6EQuY7GaQgUfVm+A9Iq/DZsiHcX+0 w67a04b/hWd/qWDbmhkMUn0KLF/bOtbzxmQEI2NHE8nTPDbens7KDgyOHBNW+z/E K5EBK+Kruxc= =Gldj -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 2, 2008, at 2:20 AM, Ronald Oussoren wrote:
On 2 Oct, 2008, at 8:08, Martin v. Löwis wrote:
You're absolutely right and that sounds good. I will update the PEP accordingly. Martin, Ronald, Sean, what timezones are you in? I am US/Eastern.
I'm in CET (Central European), that GMT+2 in DST, and GMT+1
otherwise.I'm in CET as wel.
Got it, thanks.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOUPNnEjvBPtnXfVAQJe3QP/bDyBfEbtv/gzBwAADX2eWZFjEuG4wT3E SrbE0lom9/Aa5TluTxIloGmANuiCplQD+3dfMp+cW8t8luWW7COsOz8VO5AA46e+ P3R9WbYSdrOcD+rPzQxrh81mTn9QPFDLwus9/9Q7uMqy1wMllOYt+FsDUzL0K+uv ztFSH2YqBoc= =gSfz -----END PGP SIGNATURE-----
If there's a screwup, and you need to recut the branch, you want to be sure someone else hasn't been helpful and added something else to the repo.
But you can put the tag/create the branch in any revision you want...
Suppose you have three subsequent revisions in the trunk:
A contains what you originally wanted to tag A+1 contains a change by somebody else, not to be released A+2 is the change that you made to fix a bug you noticed during the release
How do you create the release tag so that it contains change sets A and A+2, but not A+1? (and no, creating a branch just for the release is no option, because that means you have to copy all the changes you made on the branch back to the trunk)
Regards, Martin
On Thu, Oct 2, 2008 at 3:55 PM, "Martin v. Löwis" <martin@v.loewis.de>wrote:
Suppose you have three subsequent revisions in the trunk:
A contains what you originally wanted to tag A+1 contains a change by somebody else, not to be released A+2 is the change that you made to fix a bug you noticed during the release
How do you create the release tag so that it contains change sets A and A+2, but not A+1?
You always create a branch for the release (subversion doesn't make any distinction between a tag and a branch anyhow, so you might as well just make a branch).
(and no, creating a branch just for
the release is no option, because that means you have to copy all the changes you made on the branch back to the trunk)
Any by "copy" you mean "merge", right? Presumably someone is cutting a release because we believe it's done, and thus the likelihood of needing to make changes is very very low. If you indeed have the extraordinary circumstance where you have to modify the release after you make the branch, just make the change on the branch, cut the release, and merge that change back into the main line.
Version control systems are built to avoid precisely the situation which is being discussed here - we should take advantage of that.
-- Nick
You always create a branch for the release (subversion doesn't make any distinction between a tag and a branch anyhow, so you might as well just make a branch).
I don't think the tag should be edited (there are a few that were, and that's unfortunate already). For example, conversion to bzr will conclude it's a bazaar branch, not a tag.
Any by "copy" you mean "merge", right? Presumably someone is cutting a release because we believe it's done, and thus the likelihood of needing to make changes is very very low. If you indeed have the extraordinary circumstance where you have to modify the release after you make the branch, just make the change on the branch, cut the release, and merge that change back into the main line.
It's standard procedure to change the code after declaring it releasable; during the release process, the version numbers get adjusted throughout, and those changes get committed before the release tag is made.
Version control systems are built to avoid precisely the situation which is being discussed here - we should take advantage of that.
I would leave that up to the release manager.
Regards, Martin
On Thu, Oct 2, 2008 at 4:25 PM, "Martin v. Löwis" <martin@v.loewis.de>wrote:
You always create a branch for the release (subversion doesn't make any distinction between a tag and a branch anyhow, so you might as well just make a branch).
I don't think the tag should be edited (there are a few that were, and that's unfortunate already). For example, conversion to bzr will conclude it's a bazaar branch, not a tag.
I agree, that's why I think we should make a branch. Tags should be treated as immutable - it's merely an artifact of a limitation in the source control system we use that you can't make real labels.
It's standard procedure to change the code after declaring it releasable; during the release process, the version numbers get adjusted throughout, and those changes get committed before the release tag is made.
I guess my question is, is there a normal use case where the code needs to be changed for a release after the 'tag' is made? If all the changes are getting committed before the release tag is made, then what is the problem?
-- Nick
How do you create the release tag so that it contains change sets A and A+2, but not A+1? (and no, creating a branch just for the release is no option, because that means you have to copy all the changes you made on the branch back to the trunk)
creating a branch for the release is no option? that's odd, because I do that all the time. i.e.
1 - create trunk snapshot by branching 2 - build release kit from branch 3 - tweak snapshot in branch if necessary, repeat from 2 4 - when the kit is solid, tag the final branch 5 - merge relevant changes back to trunk
</F>
On Thu, Oct 2, 2008 at 5:08 PM, Fredrik Lundh <fredrik@pythonware.com>wrote:
How do you create the release tag so that it contains change sets A and A+2, but not A+1? (and no, creating a branch just for the release is no option, because that means you have to copy all the changes you made on the branch back to the trunk)
creating a branch for the release is no option? that's odd, because I do that all the time. i.e.
1 - create trunk snapshot by branching 2 - build release kit from branch 3 - tweak snapshot in branch if necessary, repeat from 2 4 - when the kit is solid, tag the final branch 5 - merge relevant changes back to trunk
I second this - it's what I've been trying to say and failing, I suppose. This seems like the natural way (and how I've done it on any other project), and avoids the need to lock out any working branch from commits. The only reason I can see for avoiding this process is if you believe that merging is somehow difficult or impossible.
-- Nick
I guess my question is, is there a normal use case where the code needs to be changed for a release after the 'tag' is made? If all the changes are getting committed before the release tag is made, then what is the problem?
The changes that need to be made are committed to the trunk (or the maintenance branch), which gets tagged when they are all made. If unrelated changed are made to the trunk, it can't be tagged anymore, hence the trunk must be frozen.
Please study the commit logs in detail if its still not clear.
Regards, Martin
creating a branch for the release is no option?
It might be, but that's for the release manager to decide, and he has chosen the alternative option of freezing the repository.
that's odd, because I do that all the time. i.e.
1 - create trunk snapshot by branching 2 - build release kit from branch 3 - tweak snapshot in branch if necessary, repeat from 2 4 - when the kit is solid, tag the final branch 5 - merge relevant changes back to trunk
It's more complicated than the current procedure.
Regards, Martin
On Fri, Oct 3, 2008 at 7:06 AM, Nicholas Bastin <nick.bastin@gmail.com> wrote:
On Thu, Oct 2, 2008 at 4:25 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
You always create a branch for the release (subversion doesn't make any distinction between a tag and a branch anyhow, so you might as well just make a branch).
I don't think the tag should be edited (there are a few that were, and that's unfortunate already). For example, conversion to bzr will conclude it's a bazaar branch, not a tag.
I agree, that's why I think we should make a branch. Tags should be treated as immutable - it's merely an artifact of a limitation in the source control system we use that you can't make real labels.
It's standard procedure to change the code after declaring it releasable; during the release process, the version numbers get adjusted throughout, and those changes get committed before the release tag is made.
I guess my question is, is there a normal use case where the code needs to be changed for a release after the 'tag' is made? If all the changes are getting committed before the release tag is made, then what is the problem?
It's happened a couple of times when I've made releases - the process I had was to automate it as much as possible, then take the generated tarball, unpack it freshly and run the full tests, and then check things like the README and all those other places. Making a release is still a pretty fiddly process, and things slip through.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 2, 2008, at 4:25 PM, Martin v. Löwis wrote:
You always create a branch for the release (subversion doesn't make
any distinction between a tag and a branch anyhow, so you might as well
just make a branch).I don't think the tag should be edited (there are a few that were, and that's unfortunate already). For example, conversion to bzr will conclude it's a bazaar branch, not a tag.
I agree.
Version control systems are built to avoid precisely the situation
which is being discussed here - we should take advantage of that.I would leave that up to the release manager.
Imposing a freeze simplifies the release process, so I would like to
keep it.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOYLAHEjvBPtnXfVAQKuQwP/RZp4SJWyG5MNSXCu2QBHHJlYIYPouz+g Ms5/nEh2IMQ0JBzkrJBAzAnP8Fgl6ofhAQkh9FntP6t7X1w9xPhcMqLbV7pSR5wG 1TKg6gWZ1woi6Ez84kc35rBdNDnKmYCLZjNz8l6lmLlfXIFopkd9ECOfYxME8nzk +DqxKHMF+j4= =L6jU -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 3, 2008, at 12:34 AM, Anthony Baxter wrote:
It's happened a couple of times when I've made releases - the process I had was to automate it as much as possible, then take the generated tarball, unpack it freshly and run the full tests, and then check things like the README and all those other places. Making a release is still a pretty fiddly process, and things slip through.
Anthony's spot on. Even with a release script and PEP 101, it's still
pretty labor intensive. Of course, Python 2.7 and 3.1 still have no
official RM <wink> so if you want firsthand experience, the
opportunity is available.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOYLY3EjvBPtnXfVAQLR1QP6A4rhYAPQ1BJwRsHPcg9aBB7jKYD7I77f T2C0+rn3303mI8zwF/iVQ+0QX7EM5MYzIniu1IReZxh+9jgZ5abyPSj3oqedpeaO XKBKzT8v5TN1G6LvdgyiUESQGE29UPSIRdMzRRurdKN0tlMZOBLYr4/nf128cNFL cLqg02NHmr4= =iLa3 -----END PGP SIGNATURE-----
On Fri, Oct 3, 2008 at 7:09 AM, Barry Warsaw <barry@python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 3, 2008, at 12:34 AM, Anthony Baxter wrote:
It's happened a couple of times when I've made releases - the process I had was to automate it as much as possible, then take the generated tarball, unpack it freshly and run the full tests, and then check things like the README and all those other places. Making a release is still a pretty fiddly process, and things slip through.
Anthony's spot on. Even with a release script and PEP 101, it's still pretty labor intensive. Of course, Python 2.7 and 3.1 still have no official RM <wink> so if you want firsthand experience, the opportunity is available.
I would actually be interested in this. However, I still am quite inexperienced and gladly step aside for anyone who's been around longer.
-- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 3, 2008, at 4:55 PM, Benjamin Peterson wrote:
On Fri, Oct 3, 2008 at 7:09 AM, Barry Warsaw <barry@python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 3, 2008, at 12:34 AM, Anthony Baxter wrote:
It's happened a couple of times when I've made releases - the
process I had was to automate it as much as possible, then take the
generated tarball, unpack it freshly and run the full tests, and then check things like the README and all those other places. Making a
release is still a pretty fiddly process, and things slip through.Anthony's spot on. Even with a release script and PEP 101, it's
still pretty labor intensive. Of course, Python 2.7 and 3.1 still have no official RM <wink> so if you want firsthand experience, the
opportunity is available.I would actually be interested in this. However, I still am quite inexperienced and gladly step aside for anyone who's been around longer.
We have our first victi^H^H^H^Holunteer! :)
Benjamin, you've done some good work on the release.py script and are
always available on IRC when I'm doing a release, so I think you'd be
a good candidate. Will you be at PyCon 2009? It would be nice to
cross-sign some gpg keys.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSPjY63EjvBPtnXfVAQLGOgP9HQm/bAWGngvMtaCI0OMA8mQGKq9oEm3/ 0McVdy9pSXoEgd+eEBhlUBzRwX+1L6O/8imnDkmP1QraHznmW0u2hB1Ufa37fqli 2c0AQhMrVMJDK4sd7gNCLdIHDgXY53qLLEMwf9W5yRZF6bTGnfpZJBI1o71HZXKE eh1d4qWz6N4= =HvdP -----END PGP SIGNATURE-----
On Fri, Oct 17, 2008 at 1:26 PM, Barry Warsaw <barry@python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 3, 2008, at 4:55 PM, Benjamin Peterson wrote:
On Fri, Oct 3, 2008 at 7:09 AM, Barry Warsaw <barry@python.org> wrote:
Anthony's spot on. Even with a release script and PEP 101, it's still pretty labor intensive. Of course, Python 2.7 and 3.1 still have no official RM <wink> so if you want firsthand experience, the opportunity is available.
I would actually be interested in this. However, I still am quite inexperienced and gladly step aside for anyone who's been around longer.
We have our first victi^H^H^H^Holunteer! :)
Benjamin, you've done some good work on the release.py script and are always available on IRC when I'm doing a release, so I think you'd be a good candidate. Will you be at PyCon 2009? It would be nice to cross-sign some gpg keys.
Yes, I plan to be attending PyCon.
-- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."
participants (10)
-
"Martin v. Löwis" -
Anthony Baxter -
Barry Warsaw -
Benjamin Peterson -
Fredrik Lundh -
Guido van Rossum -
Jesus Cea -
Nicholas Bastin -
Nick Coghlan -
Ronald Oussoren