-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, I've volunteered to be the release manager for Python 2.6 and 3.0. It's been several years since I've RM'd a Python release, and I'm happy to do it again (he says while the medication is still working :). I would like to get the next alpha releases of both versions out before Pycon, so I propose next Friday, February 29 for both. Guido reminded me that we released Python 1.6 and 2.0 together and it makes sense to both of us to do the same for Python 2.6 and 3.0. I don't think it will be that much more work (for me at least :) to release them in lockstep, so I think we should try it. I won't try to sync their pre-release version numbers except at the milestones (e.g. first beta, release candidates, final releases). I propose to change PEP 361 to outline the release schedule for both Python 2.6 and 3.0. I'm hoping we can work out a more definite schedule at Pycon, but for now I want to at least describe the lockstep release schedule and the Feb 29 date. I'd also like for us to consider doing regular monthly releases. Several other FLOSS projects I'm involved with are doing this to very good success. The nice thing is that everyone knows well in advance when the next release is going to happen, and so all developers and users know what to expect and what is needed from them. I'd like to propose that we do a joint release the last Friday of every month. For the alphas, it's basically what's in svn. This gives us some time to experiment with the process out and see if we like it enough to keep it going through the betas and final releases. Comments? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR79ek3EjvBPtnXfVAQJrmQP+KAzy0lSzake2BZsVxErD0kpFQJM+Iij0 qN86wjH0NoqARMfYKVA6eUzEY8vZPu7sJl+SjCOmhnE/KP+l/ArOdis5smiSKwQI klL4XKd/qdorTMqQ9mWgA0DeBb0Asvln9y64nxzNqgve+36q9j6ytPuRey1GjSI5 nVWoJDb3WsM= =4SRa -----END PGP SIGNATURE-----
On Fri, Feb 22, 2008 at 3:45 PM, Barry Warsaw
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi everyone,
I've volunteered to be the release manager for Python 2.6 and 3.0. It's been several years since I've RM'd a Python release, and I'm happy to do it again (he says while the medication is still working :).
Can the PSF buy you more of the meds? =)
I would like to get the next alpha releases of both versions out before Pycon, so I propose next Friday, February 29 for both.
Since they are just alphas, sure. Not like I am going to make any earth-shattering changes that soon.
Guido reminded me that we released Python 1.6 and 2.0 together and it makes sense to both of us to do the same for Python 2.6 and 3.0. I don't think it will be that much more work (for me at least :) to release them in lockstep, so I think we should try it. I won't try to sync their pre-release version numbers except at the milestones (e.g. first beta, release candidates, final releases).
I propose to change PEP 361 to outline the release schedule for both Python 2.6 and 3.0. I'm hoping we can work out a more definite schedule at Pycon, but for now I want to at least describe the lockstep release schedule and the Feb 29 date.
I'd also like for us to consider doing regular monthly releases. Several other FLOSS projects I'm involved with are doing this to very good success. The nice thing is that everyone knows well in advance when the next release is going to happen, and so all developers and users know what to expect and what is needed from them.
I'd like to propose that we do a joint release the last Friday of every month. For the alphas, it's basically what's in svn. This gives us some time to experiment with the process out and see if we like it enough to keep it going through the betas and final releases.
Comments?
If you want to do monthly alphas, go for it! But if you are going to do that frequently is a source release going to make more sense than doing binary builds? -Brett
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 22, 2008, at 6:54 PM, Brett Cannon wrote:
Hi everyone,
I've volunteered to be the release manager for Python 2.6 and 3.0. It's been several years since I've RM'd a Python release, and I'm happy to do it again (he says while the medication is still working :).
Can the PSF buy you more of the meds? =)
Depends on the jurisdiction. :)
I would like to get the next alpha releases of both versions out before Pycon, so I propose next Friday, February 29 for both.
Since they are just alphas, sure. Not like I am going to make any earth-shattering changes that soon.
Cool.
Guido reminded me that we released Python 1.6 and 2.0 together and it makes sense to both of us to do the same for Python 2.6 and 3.0. I don't think it will be that much more work (for me at least :) to release them in lockstep, so I think we should try it. I won't try to sync their pre-release version numbers except at the milestones (e.g. first beta, release candidates, final releases).
I propose to change PEP 361 to outline the release schedule for both Python 2.6 and 3.0. I'm hoping we can work out a more definite schedule at Pycon, but for now I want to at least describe the lockstep release schedule and the Feb 29 date.
I'd also like for us to consider doing regular monthly releases. Several other FLOSS projects I'm involved with are doing this to very good success. The nice thing is that everyone knows well in advance when the next release is going to happen, and so all developers and users know what to expect and what is needed from them.
I'd like to propose that we do a joint release the last Friday of every month. For the alphas, it's basically what's in svn. This gives us some time to experiment with the process out and see if we like it enough to keep it going through the betas and final releases.
Comments?
If you want to do monthly alphas, go for it! But if you are going to do that frequently is a source release going to make more sense than doing binary builds?
It very well might. See Christian Heimes's follow up re: Windows builds. OTOH, I'm okay if at least for the alphas, the binary builds lag behind the source releases, though I'd like to get the process as streamlined as possible. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8GunXEjvBPtnXfVAQIP0AQAo5F2tH1vXWbMAFGARZN576xopbQXSokX uVNXbeg5yjopCx38sHb5OCbublyIDOO8/2ubuuQ6uvAOJc3Br4BuMGHoC5ymQGqf 6pZYZLf4YUGLqFlYOB/huXpJPfH98RJJnK99zA8IQh4B7pN4xg14MF22gGij3Ybt z2hoy1EbYEk= =hW7b -----END PGP SIGNATURE-----
It very well might. See Christian Heimes's follow up re: Windows builds. OTOH, I'm okay if at least for the alphas, the binary builds lag behind the source releases, though I'd like to get the process as streamlined as possible.
I can continue to provide Windows binaries if desired. Regards, Martin
-On [20080224 19:57], "Martin v. Löwis" (martin@v.loewis.de) wrote:
I can continue to provide Windows binaries if desired.
If need be, I can help testing the build infrastructure since I have access
to various releases of Visual Studio as well.
--
Jeroen Ruigrok van der Werven
Jeroen Ruigrok van der Werven:
-On [20080224 19:57], "Martin v. Lwis" (martin@v.loewis.de) wrote:
I can continue to provide Windows binaries if desired.
If need be, I can help testing the build infrastructure since I have access to various releases of Visual Studio as well.
Me too - I still regularly build the svn version of Python, and although I don't regularly turn them into .MSI files, I'm confident I could learn how to do that ;) I understand that over time the binary process will need some tweaking, but in the general case, I expect that turning the crank for a test build needn't be that much or a burden. I expect the biggest problem is that I could no longer ignore certain extensions I don't care about, such as Tk. Cheers, Mark
Mark Hammond wrote:
Me too - I still regularly build the svn version of Python, and although I don't regularly turn them into .MSI files, I'm confident I could learn how to do that ;) I understand that over time the binary process will need some tweaking, but in the general case, I expect that turning the crank for a test build needn't be that much or a burden. I expect the biggest problem is that I could no longer ignore certain extensions I don't care about, such as Tk.
It's not too hard. Tkinter, bsddb and friends are explained in PCbuild/README.txt. You should be able to compile them in less than half an hour. For the MSI installers you also need Python 2.5, your pywin32 package and some additional tools like the help compiler and cabarc.exe. Martin: Have you solved the problem with the VS CRT redist (http://bugs.python.org/issue1569)? Maybe Mark is able to assist you. Christian
-On [20080225 16:02], Christian Heimes (lists@cheimes.de) wrote:
For the MSI installers you also need Python 2.5, your pywin32 package and some additional tools like the help compiler and cabarc.exe.
Have you looked at http://wix.sourceforge.net/ ?
--
Jeroen Ruigrok van der Werven
Jeroen Ruigrok van der Werven wrote:
Have you looked at http://wix.sourceforge.net/ ?
WiX looks interesting but I'm neither in the position to change the installer nor do I have a strong opinion. It's Martin's area of expertise. On the one hand a XML based MSI generator could be easier to maintain. On the other hand it would introduce another dependency to a 3rd party tool and things may get complicated if we leave the road. Automation tools tend to make common things really easy but special and uncommon stuff really hard. Christian
Christian Heimes wrote:
Jeroen Ruigrok van der Werven wrote:
Have you looked at http://wix.sourceforge.net/ ?
WiX looks interesting but I'm neither in the position to change the installer nor do I have a strong opinion. It's Martin's area of expertise.
On the one hand a XML based MSI generator could be easier to maintain. On the other hand it would introduce another dependency to a 3rd party tool and things may get complicated if we leave the road. Automation tools tend to make common things really easy but special and uncommon stuff really hard.
We build all our installers at Resolver Systems using Wix - dynamically generating parts of the templates and doing all sorts of weird and wonderful stuff (creating shortcuts, setting registry entries, testing dependencies, conditional includes in the installers and so on). Michael Foord
Christian _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
On the one hand a XML based MSI generator could be easier to maintain.
I've looked at it, and I seriously doubt that. In WiX, you need to specify a fixed file list (perhaps with wildcards; I'm unsure). This will be tricky for Python, where the list of files to be installed changes all the time. You *need* to have a turing-complete packing language (such as Python).
On the other hand it would introduce another dependency to a 3rd party tool and things may get complicated if we leave the road. Automation tools tend to make common things really easy but special and uncommon stuff really hard.
Exactly so. When I started with MSI generation, and tried what comes with Visual Studio, and found it unusable - it did not support Itanium, and could not be changed to support it. Regards, Martin
Martin v. Löwis wrote:
I've looked at it, and I seriously doubt that. In WiX, you need to specify a fixed file list (perhaps with wildcards; I'm unsure). This will be tricky for Python, where the list of files to be installed changes all the time.
You *need* to have a turing-complete packing language (such as Python).
You are most likely right. A pure XML based solution ain't going to work for Python. But how about a mixed solution? XML templates -> Python fu -> WiX XML -> MSI We take some XML templates, modify them from Python and add the files. Finalliy we let WiX create the MSI installer from the resulting XML file. What do you think?
Exactly so. When I started with MSI generation, and tried what comes with Visual Studio, and found it unusable - it did not support Itanium, and could not be changed to support it.
Yeah, been there, got frustrated, went back :/ Christian
Martin v. Löwis wrote:
I've looked at it, and I seriously doubt that. In WiX, you need to specify a fixed file list (perhaps with wildcards; I'm unsure). This will be tricky for Python, where the list of files to be installed changes all the time.
You *need* to have a turing-complete packing language (such as Python).
You are most likely right. A pure XML based solution ain't going to work for Python. But how about a mixed solution?
XML templates -> Python fu -> WiX XML -> MSI
We take some XML templates, modify them from Python and add the files. Finalliy we let WiX create the MSI installer from the resulting XML file.
What do you think?
I'm inclined to agree with Martin that WiX doesn't offer us much value (it offers value in many places though - just not for our requirements given Martin's msilib). I believe that once we know how to solve a particular problem, it would not be significantly easier to implement using WiX than it would using the current infrastructure. My problem is still getting my head around various MSI issues at any level (eg, bdist_msi needs some tweaking to allow for different releases of the same "package" to be recognized as such, but I'm not sure what MSI concept I'm dealing with yet...) WiX is an excellent inspiration though - if a WiX example can be found for something, it should be a significant help in implementing it via msilib. Cheers, Mark
My problem is still getting my head around various MSI issues at any level (eg, bdist_msi needs some tweaking to allow for different releases of the same "package" to be recognized as such, but I'm not sure what MSI concept I'm dealing with yet...)
Don't hesitate to ask here. Not sure what problem you are talking to specifically, but I guess you are asking for "upgrade codes"; there is also upgrade codes and package codes. Each package file should have its own unique *packageÜ code, mere rebuilding should generate a new one. msilib does that correctly. A package code code can be installed at most once on a system. Related packages for the same software should share a *product* code. Rebuilding should not change the package code (but might in msilib; I'd have to check). Again, installer enforces that a specific package code can only be installed once on a system. Python assigns a separate product code for each bug fix release. Product codes are most useful for uninstallation, e.g. to uninstall Python 2.5.1, do msiexec /x {31800004-6386-4999-a519-518f2d78d8f0} Use separate product codes if you want to allow for simultaneous versions. Subsequent versions of the same product should share an *upgrade* code. MSI will check the Upgrade table, to see whether a package with the same upgrade code (but a different product code) is already installed, and if so, whether the version range matches. If the installed product is newer, it will refuse to install the older one. If the installed product is older, it will perform an "upgrade installation", which involves uninstalling the older version (possibly on a file-by-file basis), and possibly migrating the feature selections. Python uses a single upgrade code (until 2.5.2, which introduces a separate upgrade code for Win64). It then uses version ranges to make 2.5.2 an upgrade of 2.5.1 and 2.5.0, but not of 2.4.2 (say), essentially causing only one bug fix release per 2.5.x to be installed on the system, but allowing simultaneous installation of 2.5 and 2.4 (say). With 2.5.2, simultaneous installation of Win64 and Win32 releases on a single system becomes possible - which also requires to assign separate product codes to Win64, namely 2.5.2, Win32: 6b976adf-8ae8-434e-b282-a06c7f624d2f 2.5.2, Win64: 6b976adf-8ae8-434e-b282-a06c7f624d20
WiX is an excellent inspiration though - if a WiX example can be found for something, it should be a significant help in implementing it via msilib.
The current challenge is merge modules: How can I merge the VC msm into the Python MSI (including support for SxS). Regards, Martin
What do you think?
Feel free to try it out. I'm skeptical that it will be a better overall solution than the current one - the main difference would be that, rather than me being the only one who can realistically change the packaging chain, it would be you who is the only one - which, in principle, would be fine with me. I believe you need deep inside knowledge of the MSI database format for WiX, just as you do for using the automation API. I think I could learn WiX fairly quickly after all these years of learning MSI in the first place. I think the WiX designers did right in tying WiX so close to the MSI data model, but it means that WiX makes package creation not simpler - merely more productive for the experienced user (who I hesitate to call WiXers :-) In any case, when you work with WiX, I'm sure you'll gain a lot of expert knowledge on Windows packaging. Depending on your job situation, that might pay some day :-) Regards, Martin
For the MSI installers you also need Python 2.5, your pywin32 package and some additional tools like the help compiler and cabarc.exe.
Have you looked at http://wix.sourceforge.net/ ?
Yes. Martin
Have you solved the problem with the VS CRT redist (http://bugs.python.org/issue1569)? Maybe Mark is able to assist you.
No, I still haven't found a solution. I do want to use the merge module; anything else probably isn't going to work. Regards, Martin
Martin v. Löwis wrote:
No, I still haven't found a solution. I do want to use the merge module; anything else probably isn't going to work.
Da...ng Didn't you prepare a new MSI installer for 3.0a2 that includes the VS Redist MSM for X86? I vaguely remember that you've replaced my installer with a new one. The issue should be resolved before Python 2.6 and 3.0 are reaching beta stage. Maybe we can get some help from outside? Christian
No, I still haven't found a solution. I do want to use the merge module; anything else probably isn't going to work.
Da...ng Didn't you prepare a new MSI installer for 3.0a2 that includes the VS Redist MSM for X86? I vaguely remember that you've replaced my installer with a new one.
Right. I produced a package that ships the CRT, but not by using the merge module. Instead, I arranged to include sufficient copies of the manifest file to make it work in the non-admin installation (and yes, you do need to install multiple copies of it - just see the 3.0a2 MSI file).
The issue should be resolved before Python 2.6 and 3.0 are reaching beta stage. Maybe we can get some help from outside?
Perhaps. I'm confident that I can find a solution when I get the time; I'm not so confident that I can find the time, though. Of course, I would prefer if the outside help would propose something better than "switch to this completely different technology; it may work" (unless a complete working solution is presented in that other technology, and as long as that other technology still creates MSI files with free-as-in-beer tools). In any case, contributions are welcome. Regards, Martin
(unless a complete working solution is presented in that other technology, and as long as that other technology still creates MSI files with free-as-in-beer tools).
Just out of interest, what's the reason for enforcing that the installer must be an MSI? Or, rather, if I were to present an alternative .exe installer that ticks all of the above boxes, exceeds the capabilities of the current installer and above all is easier to extend and maintain -- would that be a non-starter because it's not an MSI? Trent.
(unless a complete working solution is presented in that other technology, and as long as that other technology still creates MSI files with free-as-in-beer tools).
Just out of interest, what's the reason for enforcing that the installer must be an MSI? Or, rather, if I were to present an alternative .exe installer that ticks all of the above boxes, exceeds the capabilities of the current installer and above all is easier to extend and maintain -- would that be a non-starter because it's not an MSI?
Not necessarily - it is just very hard to provide the same features as MSI, but with a different tool. It seems that most tools have given up the battle against MSI, and now provide just another layer on top of MSI (just as my msilib does, or WiX). Regards, Martin
-On [20080225 23:03], "Martin v. Löwis" (martin@v.loewis.de) wrote:
No, I still haven't found a solution. I do want to use the merge module; anything else probably isn't going to work.
I updated the ticket with some links to how to approach this issue.
--
Jeroen Ruigrok van der Werven
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 24, 2008, at 1:57 PM, Martin v. Löwis wrote:
It very well might. See Christian Heimes's follow up re: Windows builds. OTOH, I'm okay if at least for the alphas, the binary builds lag behind the source releases, though I'd like to get the process as streamlined as possible.
I can continue to provide Windows binaries if desired.
Great, thanks! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8MuDXEjvBPtnXfVAQJeJwP/R8MMAhOsyRtpxIISEUoqMGDJksI5EtVM PcsxNO1p0MGcHfm5lNg0YNYwxsfc/0ghkRbsidegvcyN6BZWgHSaA7I0O1cBTG1x R4eNmLJBWCOcJNmTGgxCA7G8eEHTNTxneaQ0APO+yQbbHS/eyGGMcmFldNMkDqNO ycqikt0XiWI= =M3eC -----END PGP SIGNATURE-----
Barry Warsaw
On Feb 24, 2008, at 1:57 PM, Martin v. Löwis wrote:
It very well might. See Christian Heimes's follow up re: Windows builds. OTOH, I'm okay if at least for the alphas, the binary builds lag behind the source releases, though I'd like to get the process as streamlined as possible.
I can continue to provide Windows binaries if desired.
Great, thanks!
Note that my buildbot is still also building MSIs each night based on the svn head for 2.5, 2.6 and 3.0, and uploading them back to python.org (viewable at http://www.python.org/dev/daily-msi). So at least for an alpha based on the current SVN trunk, that might be an easy place to grab a binary snapshot from, unless I'm missing something. Conversely, the machine is there to make builds upon request, I presume, depending on the master configuration. I know Martin set the current scheme up. -- David
+1 to everything -- n
On Fri, Feb 22, 2008 at 3:45 PM, Barry Warsaw
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi everyone,
I've volunteered to be the release manager for Python 2.6 and 3.0. It's been several years since I've RM'd a Python release, and I'm happy to do it again (he says while the medication is still working :). I would like to get the next alpha releases of both versions out before Pycon, so I propose next Friday, February 29 for both.
Guido reminded me that we released Python 1.6 and 2.0 together and it makes sense to both of us to do the same for Python 2.6 and 3.0. I don't think it will be that much more work (for me at least :) to release them in lockstep, so I think we should try it. I won't try to sync their pre-release version numbers except at the milestones (e.g. first beta, release candidates, final releases).
I propose to change PEP 361 to outline the release schedule for both Python 2.6 and 3.0. I'm hoping we can work out a more definite schedule at Pycon, but for now I want to at least describe the lockstep release schedule and the Feb 29 date.
I'd also like for us to consider doing regular monthly releases. Several other FLOSS projects I'm involved with are doing this to very good success. The nice thing is that everyone knows well in advance when the next release is going to happen, and so all developers and users know what to expect and what is needed from them.
I'd like to propose that we do a joint release the last Friday of every month. For the alphas, it's basically what's in svn. This gives us some time to experiment with the process out and see if we like it enough to keep it going through the betas and final releases.
Comments? - -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR79ek3EjvBPtnXfVAQJrmQP+KAzy0lSzake2BZsVxErD0kpFQJM+Iij0 qN86wjH0NoqARMfYKVA6eUzEY8vZPu7sJl+SjCOmhnE/KP+l/ArOdis5smiSKwQI klL4XKd/qdorTMqQ9mWgA0DeBb0Asvln9y64nxzNqgve+36q9j6ytPuRey1GjSI5 nVWoJDb3WsM= =4SRa -----END PGP SIGNATURE----- _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/nnorwitz%40gmail.com
Barry Warsaw wrote:
I'd also like for us to consider doing regular monthly releases. Several other FLOSS projects I'm involved with are doing this to very good success. The nice thing is that everyone knows well in advance when the next release is going to happen, and so all developers and users know what to expect and what is needed from them.
I'd like to propose that we do a joint release the last Friday of every month. For the alphas, it's basically what's in svn. This gives us some time to experiment with the process out and see if we like it enough to keep it going through the betas and final releases.
Thanks for volunteering for the job, Barry! +1 for release early, release often but I want to point out a resource issue that may speak against a monthly release cycle. The Windows binaries still require a large amount of attention and human interaction. The last Windows binaries were build by me and I spent half the night ironing out issues and testing the installers. As far as I know the team only Martin and I have the infrastructure and tools to build the Windows binaries. We could cut down the time requirements by shipping only normal binaries instead of PGO (profile guided optimization) binaries. IMHO we could also skip the AMD64 builds until we have reached beta stage. But it's still going to cost either Martin or me the better half of a Friday night. I won't have time to assist with the Windows builds next Friday. I'm more than busy with personal life and job interviews. Hopefully I'm going to find a job that allows me to work on the Python core as much as during the past few months. That's for the Windows builds. Now I have a list of bugs and features I like to see fixed / applied before the next release: http://bugs.python.org/issue1692335 Fix exception pickling: Move initial args assignment to BaseException.__new__ http://bugs.python.org/issue1792 (trivial performance patch for marshal) http://bugs.python.org/issue1569 MS VCRT redist issue. IIRC Martin had a working solution for it in his sandbox. http://bugs.python.org/issue1657 my kqueue and epoll patch, just needs another review Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 24, 2008, at 9:19 AM, Christian Heimes wrote:
Barry Warsaw wrote:
I'd also like for us to consider doing regular monthly releases. Several other FLOSS projects I'm involved with are doing this to very good success. The nice thing is that everyone knows well in advance when the next release is going to happen, and so all developers and users know what to expect and what is needed from them.
I'd like to propose that we do a joint release the last Friday of every month. For the alphas, it's basically what's in svn. This gives us some time to experiment with the process out and see if we like it enough to keep it going through the betas and final releases.
Thanks for volunteering for the job, Barry!
+1 for release early, release often but I want to point out a resource issue that may speak against a monthly release cycle. The Windows binaries still require a large amount of attention and human interaction. The last Windows binaries were build by me and I spent half the night ironing out issues and testing the installers. As far as I know the team only Martin and I have the infrastructure and tools to build the Windows binaries.
From the follow ups, it sounds like others can pitch in here. A question though: is it reasonable to hold up the monthly release because a binary build we're going to make available can't be done at the same time? My preference (at least for the alphas) is "no". If we can make a source release, and if we can build a binary release from exactly the same revision, then we should go ahead and release. I'd rather get the alpha out there and in people's hands. We'll almost certainly be stricter for the candidates, finals, and maybe betas.
We could cut down the time requirements by shipping only normal binaries instead of PGO (profile guided optimization) binaries. IMHO we could also skip the AMD64 builds until we have reached beta stage. But it's still going to cost either Martin or me the better half of a Friday night.
Dang. I actually don't know how long it's going to take me to do the source release, but I hope it's no more than 3 or 4 hours.
I won't have time to assist with the Windows builds next Friday. I'm more than busy with personal life and job interviews. Hopefully I'm going to find a job that allows me to work on the Python core as much as during the past few months.
When's the PSF gonna start hiring? :)
That's for the Windows builds. Now I have a list of bugs and features I like to see fixed / applied before the next release:
http://bugs.python.org/issue1692335 Fix exception pickling: Move initial args assignment to BaseException.__new__
http://bugs.python.org/issue1792 (trivial performance patch for marshal)
http://bugs.python.org/issue1569 MS VCRT redist issue. IIRC Martin had a working solution for it in his sandbox.
http://bugs.python.org/issue1657 my kqueue and epoll patch, just needs another review
So, as I mentioned in my last reply, I'm planning to only allow critical bugs (as described in roundup) hold up the release. Right now there are no critical bugs open. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8MuAHEjvBPtnXfVAQJ4JQP9F8AijArF8KhyxC7lp0ePDBGphgZjq7h8 9vZZ13oGOCtED/6M4bGDaZWrI1LEcj3iuf61Kdk6KwaeAi3dnGHkrP1XOTxZbLcz 8euKbC8JhBHan/A4SO4+xzxx4ZI9vCMRQqe+sLOQJsE9vH+4UMU1FDrhROxYwLbb aG0+fzGPdzA= =zpPQ -----END PGP SIGNATURE-----
Barry Warsaw wrote:
From the follow ups, it sounds like others can pitch in here. A question though: is it reasonable to hold up the monthly release because a binary build we're going to make available can't be done at the same time?
My preference (at least for the alphas) is "no". If we can make a source release, and if we can build a binary release from exactly the same revision, then we should go ahead and release. I'd rather get the alpha out there and in people's hands.
We'll almost certainly be stricter for the candidates, finals, and maybe betas.
I agree. It's not reasonable to hold of alphas because the Windows binaries may be released a few days later. Do we need official Windows binaries for alphas at all? Martin's buildbot creates nightly Windows builds. We could point users to the nightly builds and ask them to test the version.
Dang. I actually don't know how long it's going to take me to do the source release, but I hope it's no more than 3 or 4 hours.
I guess it's less than 2 hours. You can prepare most of the work like the announcements a couple of days earlier. I (perhaps naively) assume you have to smack the whip to get everything in place, do the svn cp to tag, svn export, tar cz, tar xzf && ./configure && make && make test dance and upload the tar.gz. Am I missing something important? :]
When's the PSF gonna start hiring? :)
Dunno :) But I'm probably the last in a long line of Python core developers to get hired. Don't forget I'm still fresh and a junior core developer. *jk*
So, as I mentioned in my last reply, I'm planning to only allow critical bugs (as described in roundup) hold up the release. Right now there are no critical bugs open.
#1569 is critical but not important enough to stop an alpha. As I said in the other mail it should be fixed for the first beta and must be fixed for the first rc. Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2008, at 7:11 PM, Christian Heimes wrote:
Barry Warsaw wrote:
From the follow ups, it sounds like others can pitch in here. A question though: is it reasonable to hold up the monthly release because a binary build we're going to make available can't be done at the same time?
My preference (at least for the alphas) is "no". If we can make a source release, and if we can build a binary release from exactly the same revision, then we should go ahead and release. I'd rather get the alpha out there and in people's hands.
We'll almost certainly be stricter for the candidates, finals, and maybe betas.
I agree. It's not reasonable to hold of alphas because the Windows binaries may be released a few days later. Do we need official Windows binaries for alphas at all? Martin's buildbot creates nightly Windows builds. We could point users to the nightly builds and ask them to test the version.
That would be find with me. Where are those Windows binaries available for download from?
Dang. I actually don't know how long it's going to take me to do the source release, but I hope it's no more than 3 or 4 hours.
I guess it's less than 2 hours. You can prepare most of the work like the announcements a couple of days earlier. I (perhaps naively) assume you have to smack the whip to get everything in place, do the svn cp to tag, svn export, tar cz, tar xzf && ./configure && make && make test dance and upload the tar.gz. Am I missing something important? :]
Dunno yet! It's been years since I did a release and I really want to check out Anthony's welease tool this time. I may not have time before Friday to look at this though.
When's the PSF gonna start hiring? :)
Dunno :) But I'm probably the last in a long line of Python core developers to get hired. Don't forget I'm still fresh and a junior core developer. *jk*
:)
So, as I mentioned in my last reply, I'm planning to only allow critical bugs (as described in roundup) hold up the release. Right now there are no critical bugs open.
#1569 is critical but not important enough to stop an alpha. As I said in the other mail it should be fixed for the first beta and must be fixed for the first rc.
It's not marked critical in roundup, and that's the only thing I'm going by! But it doesn't seem critical in the sense that it should hold up the alpha release, IMO. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8QF5nEjvBPtnXfVAQJhrgP/Xz3IQrlCB9QPGsMGIL+xG3I5t+aThNg6 4n/bMjt4DRzTCRiNBjUllyCb5+VtPfTZu2wFVdi5I7NLMDG4WI4jfDGZlhvodbHW TPG/7bN/ykx9yE1hUPI5X+Kqrg0lG7Tbp9Zev5eHJCMwParSVu+hfWqD48+1bQqw JGfzz8AlqE0= =PQgE -----END PGP SIGNATURE-----
Barry Warsaw wrote:
That would be find with me. Where are those Windows binaries available for download from?
The Windows builds are hidden in the development section. It took me 10 minutes to find them because I was searching in the download section and for nightly builds. The *daily* builds are available at http://www.python.org/dev/daily-msi/ Christian
The Windows builds are hidden in the development section. It took me 10 minutes to find them because I was searching in the download section and for nightly builds. The *daily* builds are available at http://www.python.org/dev/daily-msi/
The builds occur 11:00 UTC (2.5), 12:00 UTC (2.6) and 13:00 UTC (3.0). What that's at day or at night depends on where you live :-) Regards, Martin
Martin v. Löwis wrote:
The Windows builds are hidden in the development section. It took me 10 minutes to find them because I was searching in the download section and for nightly builds. The *daily* builds are available at http://www.python.org/dev/daily-msi/
The builds occur 11:00 UTC (2.5), 12:00 UTC (2.6) and 13:00 UTC (3.0). What that's at day or at night depends on where you live :-)
Trust me, the day and night cycle of our sun can be unrelated to the day and night cycle of my life. I define morning as the time span after my first coffee. I sometimes work until dawn so technically speaking 11:00 UTC could fit my definition of nightly build. :) Christian
participants (11)
-
"Martin v. Löwis"
-
Barry Warsaw
-
Brett Cannon
-
Christian Heimes
-
Christian Heimes
-
David Bolen
-
Jeroen Ruigrok van der Werven
-
Mark Hammond
-
Michael Foord
-
Neal Norwitz
-
Trent Nelson