[Python-Dev] Community buildbots (was Re: User's complaints)

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 13, 2006, at 2:03 PM, glyph at divmod.com wrote:

> Having been exhorted (or maybe I mean "excoriated") by your  
> friendly release
> manager earlier this week to post my comments and criticisms about  
> Python here
> rather than vent in random IRC chatter, I feel morally compelled to  
> comment.

And I'm glad you did because you made some excellent comments.

> However, although I've seen lots of discussions of what "average"  
> code might
> break when exposed to new versions of Python, these discussions  
> tend to be
> entirely hypothetical.  Do the core Python developers typically run  
> the test
> suites of major Python applications when considering major changes,  
> such as
> Zope, Plone, TurboGears, and of course Twisted?  Not that breakages  
> would be
> considered unacceptable -- some gain is surely worth the cost --  
> but to
> establish some empirical level of burden on the community?

I do plan on very soon running Mailman's meager test suite and  
running more manual functional tests on Python 2.5b2.  Compared to  
Twisted, Mailman is pretty simple and doesn't do that much fancy  
stuff so I suspect that it'll mostly work, but you never know until  
you try it.  I'd support adding Mailman to a community buildbot army,  
although I don't personally have the cycles to build out such a beast.

I also plan on testing my Real Job's embedded application against  
Python 2.5b2 sometime this week or next.  We're on Python 2.4.2 atm  
and that is much more complicated because of all the C API we use.   
I'm less sanguine about breakage there, but I'll post here if I find  
anything egregious (fortunately, we have an extensive test suite to  
rely upon).

> Twisted itself is a fairly
> representative "application using Twisted", so when something  
> breaks "average"
> Twisted code, I know about it right away.  Python is less an  
> application using
> Python: the standard library is rather passive (there is no "end-to- 
> end"
> application path to test, only individual functions and classes),  
> and the test
> coverage of included Python modules is rather spotty.

This really is an excellent point and makes me think that we may want  
to consider elaborating on the Python release cycle to include a  
gamma phase or a longer release candidate cycle.  OT1H I think there  
will always be people or projects that won't try anything until the  
gold release, and that if we've broken anything in their code we  
simply won't know it until after that, no matter how diligent we  
are.  OTOH, a more formal gamma phase would allow us to say  
"absolutely no changes are allowed now unless it's to fix backward  
compatibility".  No more sneaking in new sys functions or types  
module constants <wink> during the gamma phase.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iQCVAwUBRLanoHEjvBPtnXfVAQJB6gP/SwVtejenN0/7tszePbJ4O20l98k2Z/7N
rs9dfF2+Jcy/OLzSCcW/OW4iVf+iPJMWUNqHEPFDQO/+nVifh8pjjWGTQJMc8ynm
7HNCk/ZciZyNqeGbmGvzHoywmrldbDPkx5Y6Fo13yel0slw2Qo6gC6W8aygi7giP
boJiovnaKH0=
=wRxy
-----END PGP SIGNATURE-----