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