[Python-3000] Python 2.6 and 3.0

[Barry Warsaw]

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