-----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.