-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just announced the 2.6a1 and 3.0a3 releases, and am thawing both branches. Just some quick feedback in case anybody is interested. First, huge thanks go to Brett Cannon, Neal Norwitz, Mark Dickinson and Fred Drake for their help last night. Apologies also to them for my drunken rants on jabber :). Also thanks to Martin von Loewis for the Windows msi's for Python 2.6. I'm sure Martin will soon provide msi's for 3.0, but these are not yet available. Some other random notes: Brett fixed test_profile in 3.0 last night but test_cProfile was still broken. I disabled the test via a TestSkipped and set this to expected in regrtest.py. This test should be fixed and the expected skip removed. I will definitely need help keeping the various NEWS files up to date. I don't see any way that I'll be able to spend time on these when I'm cutting a release. Python 2.6 NEWS was simply impossible to proofread because of its sheer size and the fact that it was the first alpha of the series. PEP 101 describes 4 news files: Misc/NEWS and Lib/idlelib/NEWS.txt for both 2.6 and 3.0. I am urgently requesting that when people commit newsworthy items to the Python releases that they keep the NEWS files up-to-date. This is especially tricky for code merged between the two versions. Thanks to Neal for looking over 3.0's NEWS file last night. As RM, I am going to operate on the assumption that the NEWS files are up-to-date. I'd be thrilled if someone volunteered to be the "NEWS czar" -- we all know when the next alpha release is coming (Friday March 25), so this czar would be responsible for watching commits and making sure that NEWS was updated as appropriate, or harassing the committer into updating NEWS to describe their new feature. If you'd like to be this NEWS czar, please let me know. With apologies to Anthony, welease is crack. I made pretty good progress once I ditched it and starting doing things manually. Between now and the next alpha I intend to work on a command line script to help with releases. If you're interested in helping, let me know. PEP 101 is sorely out of date, especially with regards to updating web content and the Python documentation. I think I now know how to update the python.org web site, but the new Python documentation format is still a mystery to me. If someone would like to help update PEP 101 for the documentation steps, please let me know. PEP 101 also describes some steps for updating the distutils version numbers. These instructions seemed stale too. If you know anything about distutils version numbers and the process for updating them, please contact me. There's no Misc/RPM/python-3.0.spec file so I skipped that step too. Sean, do you know anything about that? That's it. See you again next time :). Let me know if you notice anything broken about the releases. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8mphXEjvBPtnXfVAQKPcwQAqQVP+IWO60/m1Rm1OKpcGfpS+BZILKvj LkLJamZ6gvupFeJj1kCr6eAl62Mqaec2Z29jsnXK9TfAogGGVcW21a98rgcQUong fRh34dt1YGVMcqw4r8G60kqYQG4caGJ9tS5oKEXq+lYWPfirLZ7mC1SkkfnJ9mVd Cscr0ZAYayI= =nnlY -----END PGP SIGNATURE-----
Barry Warsaw wrote:
I will definitely need help keeping the various NEWS files up to date. I don't see any way that I'll be able to spend time on these when I'm cutting a release. Python 2.6 NEWS was simply impossible to proofread because of its sheer size and the fact that it was the first alpha of the series.
PEP 101 describes 4 news files: Misc/NEWS and Lib/idlelib/NEWS.txt for both 2.6 and 3.0. I am urgently requesting that when people commit newsworthy items to the Python releases that they keep the NEWS files up-to-date. This is especially tricky for code merged between the two versions. Thanks to Neal for looking over 3.0's NEWS file last night. As RM, I am going to operate on the assumption that the NEWS files are up-to-date. I'd be thrilled if someone volunteered to be the "NEWS czar" -- we all know when the next alpha release is coming (Friday March 25), so this czar would be responsible for watching commits and making sure that NEWS was updated as appropriate, or harassing the committer into updating NEWS to describe their new feature. If you'd like to be this NEWS czar, please let me know.
I *never* sync changes from trunk Misc/NEWS to py3k Misc/NEWS. From my point of view it doesn't make sense to put Python 2.6 changes in the same section as Python 3.0 changes. Moving changes from to the right section would put a large and unnecessary burden on me. In general every change of the 2.6 source tree makes it into 3.0. Exceptions to the rule is stuff that makes no sense like 3.0 compatibility and warnings. Thumb rule: Changes, bug fixes and new features in 2.6 are also in 3.0 except they are outruled by a Python 3.0 feature. Several people including me and Guido himself are watching the cvs lists. We make sure everybody adds an entry to Misc/NEWS whenever a bug is fixed or a new feature is added. Otherwise we crack the whip ^H^H^H contact the committer. You can be sure that at least 98% of all closed bug reports, feature request and important changes have an entry in Misc/NEWS. So in general Misc/NEWS isn't an issue but Docs/whatsnew/ is. Only a couple of people - mostly Georg and Andrew - are updating the files. Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 1, 2008, at 3:04 PM, Christian Heimes wrote:
I *never* sync changes from trunk Misc/NEWS to py3k Misc/NEWS. From my point of view it doesn't make sense to put Python 2.6 changes in the same section as Python 3.0 changes. Moving changes from to the right section would put a large and unnecessary burden on me. In general every change of the 2.6 source tree makes it into 3.0. Exceptions to the rule is stuff that makes no sense like 3.0 compatibility and warnings.
Thumb rule: Changes, bug fixes and new features in 2.6 are also in 3.0 except they are outruled by a Python 3.0 feature.
Several people including me and Guido himself are watching the cvs lists. We make sure everybody adds an entry to Misc/NEWS whenever a bug is fixed or a new feature is added. Otherwise we crack the whip ^H^H^H contact the committer. You can be sure that at least 98% of all closed bug reports, feature request and important changes have an entry in Misc/NEWS.
Great, this is all I'm really asking for! The point of my unconscionable rant :) was that I think it's unfeasible to update the NEWS files at release time. Knowing that you, Guido and others are keeping an eye on commits and an iron hand on the NEWS files makes me as the RM rest comfortably. :)
So in general Misc/NEWS isn't an issue but Docs/whatsnew/ is. Only a couple of people - mostly Georg and Andrew - are updating the files.
I think it's okay if these lag behind during the alphas, but it would be good to start whipping these in shape by the time we start releasing betas. Thanks, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8ncx3EjvBPtnXfVAQJeNQP+L2wK4CmGfwzgsQUHQISniaJ2rREBhJua sJwqGNpBhnf6Uc8jJz+JRiexPdCW4AlH34FtHkyRkw2ZIVWwd6sO+7ixQPk0A/TP +gGk1uST/sjPG3q8T5u9OElri5SoTqJzEgWMkTiGhwYouSvOjpW/GFFREySU68Tk h9XGzJFZex0= =aXqC -----END PGP SIGNATURE-----
With apologies to Anthony, welease is crack. I made pretty good progress once I ditched it and starting doing things manually. Between now and the next alpha I intend to work on a command line script to help with releases. If you're interested in helping, let me know.
I guess every release manager is free to come up with his own set of tools, but I feel you've given up too quickly (or started too late - perhaps a test release run a few days before the release would have helped). In any case, I'm willing to help with welease, but not with yet another release tool. If you primarily complain about the GUIness of welease, I could help with a command line version of it. Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 1, 2008, at 5:37 PM, Martin v. Löwis wrote:
With apologies to Anthony, welease is crack. I made pretty good progress once I ditched it and starting doing things manually. Between now and the next alpha I intend to work on a command line script to help with releases. If you're interested in helping, let me know.
I guess every release manager is free to come up with his own set of tools, but I feel you've given up too quickly (or started too late - perhaps a test release run a few days before the release would have helped).
Maybe.
In any case, I'm willing to help with welease, but not with yet another release tool. If you primarily complain about the GUIness of welease, I could help with a command line version of it.
The dependency on gtk is unnecessary and means it can effectively only be run on Linux. Specifically it means I can't do releases on OS X. I don't see much benefit in having a gui tool for doing releases. Some of the problems I had include having to run glade3 in order to update the menus which allow you to choose which release you were going to make. It only new about py24 and 25 maintenance. No knock on Anthony there, since those are the releases he had to make, but I shouldn't have to edit the interface description files to add new release versions. Also, the scheme to compare IDLE versions seemed way off. Maybe that's another thing that makes sense for py24 and py25 but it definitely didn't work for py30. The much more serious problem, and where I stopped, is that welease broke on code containing the with statement. I don't remember the details because at that point I was pretty tired and hadn't made any progress on the releases, but I /think/ the problem is that welease runs on a different version of Python than it's checking so it can't handle syntactic differences and such. The kind of tool I think we need is a fairly straightforward command line tool, but one that would not just check that things are done, but also do them. E.g. the tool would keep track of all the little places where version numbers and copyright years need updating. The tool would actually make those changes, and using $EDITOR would show them to you for confirmation. It would pause at steps that require coordination, such as when things need to be committed or signed, or when you're waiting from input from others. It would have a dry-run mode and it would fairly closely follow PEP 101. Anyway, that's the kind of tool I plan on building (or perhaps with help from others -- hi Benjamin) for the next alpha round. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8ngyHEjvBPtnXfVAQKYaAP+JzIj8HiwVYIJLMyxh+Glq57YQozOh2bB XILPBwUyppBBkezcT6IWAnawo5YUGXwg1tJjS/OsqSnIoajnRQCzzR6X896qXUAn asgXKTydmf553iSD03OG4K38UsdeD6uPUWN9zg/bceKaH2GM72p6md3Wepof4DuE UdTGgXENXOI= =uKmC -----END PGP SIGNATURE-----
Barry> The dependency on gtk is unnecessary and means it can effectively Barry> only be run on Linux. Specifically it means I can't do releases Barry> on OS X. I don't see much benefit in having a gui tool for doing Barry> releases. Gtk and Glade are available through MacPorts, at least according to "port search ...". Skip
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 1, 2008, at 7:28 PM, skip@pobox.com wrote:
Barry> The dependency on gtk is unnecessary and means it can effectively Barry> only be run on Linux. Specifically it means I can't do releases Barry> on OS X. I don't see much benefit in having a gui tool for doing Barry> releases.
Gtk and Glade are available through MacPorts, at least according to "port search ...".
True, but it's just more moving parts to break, especially when I don't really feel a u/i buys you much[*]. - -Barry [*] Skip knows me as a diehard XEmacser so that statement can pretty much define my standard answer to all such questions. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8x/LXEjvBPtnXfVAQKnFAP/RDKzhQsIDuc8joSR3G2mrKv7jH+6tl04 Fq3d++1jFjE5cBiY9uDL2/799wqUKvevx2QnGrON1ins9xuYGh5/xY9w4JvbI8aX zLq/RjNFzPl/YnMCX7OSUBjbQoE3sr+dgUpLurImsJxWaFcjqufzQuno6N0sqvWg sevJTwfBkOE= =HfWd -----END PGP SIGNATURE-----
Barry> True, but it's just more moving parts to break, especially when I Barry> don't really feel a u/i buys you much[*]. Barry> [*] Skip knows me as a diehard XEmacser so that statement can Barry> pretty much define my standard answer to all such questions. :) So if we put together a "gui" which uses Johan Vroman's defunct Emacs Lisp forms package you'd be okay with that? <wink> Skip
Martin v. Löwis wrote:
I guess every release manager is free to come up with his own set of tools, but I feel you've given up too quickly (or started too late - perhaps a test release run a few days before the release would have helped).
In any case, I'm willing to help with welease, but not with yet another release tool. If you primarily complain about the GUIness of welease, I could help with a command line version of it.
[python dev only] It may sound like a dumb question by why do we need a release tool at all? I was involved in the release process of 3.0a2. Almost every step of the build process required human interaction. I don't want to diminish the effort that was put into welease though. But maybe (!) the same time spent for fixing some bugs would have helped the RM more. Christian
It may sound like a dumb question by why do we need a release tool at all? I was involved in the release process of 3.0a2. Almost every step of the build process required human interaction. I don't want to diminish the effort that was put into welease though. But maybe (!) the same time spent for fixing some bugs would have helped the RM more.
I think you underestimate the number of changes that the RM needs to make manually, the the ease at which some of these steps get forgotten. Just take a look at the changes in r60911 and r60913, or r61144, r61147, r61150, r61151. Would you have found and remembered all the changes necessary? It helps *tremendously* if a tool tells you that you didn't miss any of the mechanic edits. Then, it also helps if the tool performs some of the mechanic steps, like: - tagging the tree (would you get the svn command line right the first time?) - exporting the tree, and creating the tar files (would you remember to touch the AST files that need more recent time stamps than their respective sources?) - uploading the tar files to dinsdale (do you remember the path on dinsdale the files need to go to?) Barry apparently wants it to go even further, making many of the edits for you. Creating the Windows installer is comparatively much less error-prone (although I do sometimes forget to update Python/sysmodule.c when I switch my sandbox to the release tag). Regards, Martin
Christian Heimes writes:
It may sound like a dumb question by why do we need a release tool at all? I was involved in the release process of 3.0a2. Almost every step of the build process required human interaction.
Interaction, yes, but often it can be reduced to "Abort, retry, fail?"
I don't want to diminish the effort that was put into welease though. But maybe (!) the same time spent for fixing some bugs would have helped the RM more.
Which RM? Barry was hoping to get some useful process support at very low cost; that apparently didn't work out. But welease "is" Anthony's RM process, and surely it he considered it an investment in on-going quality or efficiency, or he wouldn't have done it. The fact that Barry found Anthony's process unusable is IMO not a reflection on either Barry or Anthony's code. Release processes seem to be highly personal, even within the same project. My own project (XEmacs) has 3 concurrent processes going at any one time (stable core, unstable core, stdlib). In my time with the project, stable core has seen two RM successions, unstable core has seen four, and stdlib has seen two. In no case did the new RM adopt the tools of any of his predecessors, but in two cases one person was a successor twice, and in both cases they reverted to their old tools. All processes seem to have been of roughly the same quality (my opinion, there are no metrics available). Been-there-done-that-shredded-the-T-shirt-in-the-process-ly y'rs,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 1, 2008, at 10:29 PM, Stephen J. Turnbull wrote:
The fact that Barry found Anthony's process unusable is IMO not a reflection on either Barry or Anthony's code. Release processes seem to be highly personal, even within the same project. My own project (XEmacs) has 3 concurrent processes going at any one time (stable core, unstable core, stdlib). In my time with the project, stable core has seen two RM successions, unstable core has seen four, and stdlib has seen two. In no case did the new RM adopt the tools of any of his predecessors, but in two cases one person was a successor twice, and in both cases they reverted to their old tools. All processes seem to have been of roughly the same quality (my opinion, there are no metrics available).
I agree with all of this, and I definitely never meant to impugn Anthony's hack. However, I would categorize every release tool I've ever used (both bought and built, in a commercial or FLOSS environment) as "a hack". Releasing something as complex as Python is just going to be a PITA, so all the RM is looking for is a hack that fits his hands better and does just enough to lower his threshold of pain, or ToP (tm), to a level where he doesn't want to spend his time waiting for the next step by plunging ice picks into his earholes. I'm sure when Anthony releases Python 2.9 <wink> he'll curse my release tool too. Or he'll do the smart thing and as Stephen suggests, just ditch my pile of crap and resurrect welease. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8yAg3EjvBPtnXfVAQIW2QP/e0Ny+l8mYGrOzmVJ1zCDZp9cdvBVgEXB fBWc0UPjyBRhmVBoeZ773R5j/IMlsLCetp2VKDkDCutq4PRo9z78ZjrYE2M2+RZP rigMxReSvv5Nw83kOXRy99jQva0ptjnYw2Gdpd1nhtlVSrRmEXaLnVF52Z2hLgul Q9JkBpg7kr8= =PEaE -----END PGP SIGNATURE-----
Barry Warsaw schrieb:
PEP 101 is sorely out of date, especially with regards to updating web content and the Python documentation. I think I now know how to update the python.org web site, but the new Python documentation format is still a mystery to me. If someone would like to help update PEP 101 for the documentation steps, please let me know.
Well, it's not very hard to guess who this someone is, is it? I've updated PEP 101, except for the part where the docs are uploaded to the website, I've no idea if the FTP paths etc. are still valid. For the next releases, if you want to do documentation packages, please feel free to contact me, I'll be happy to help! Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 2, 2008, at 1:54 AM, Georg Brandl wrote:
Barry Warsaw schrieb:
PEP 101 is sorely out of date, especially with regards to updating web content and the Python documentation. I think I now know how to update the python.org web site, but the new Python documentation format is still a mystery to me. If someone would like to help update PEP 101 for the documentation steps, please let me know.
Well, it's not very hard to guess who this someone is, is it?
Actually, I honestly didn't know... sorry Georg!
I've updated PEP 101, except for the part where the docs are uploaded to the website, I've no idea if the FTP paths etc. are still valid.
Thanks, this is a big help. I'll double check the ftp paths, but I think they haven't changed.
For the next releases, if you want to do documentation packages, please feel free to contact me, I'll be happy to help!
Great, thanks! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8yBVHEjvBPtnXfVAQJemgP/aE/a54SaKc7Ls9osae+g57zcYB7d95FX O/HcE3/QFJCQeBquTfwbOV8doyAYHFDDIw8U2GIvgppLjPEqHAJzKfBqeQIILM3a uZM/4yUUcnnI8UQYhi4u+maztv6YwQxyKj9sLuK9GFncxk1B1z7zW4WcWISoet3H j3XC4eFVvjM= =SDdJ -----END PGP SIGNATURE-----
participants (6)
-
"Martin v. Löwis" -
Barry Warsaw -
Christian Heimes -
Georg Brandl -
skip＠pobox.com -
Stephen J. Turnbull