[Python-Dev] Community buildbots and Python release quality metrics

[Nick Coghlan]

glyph at divmod.com wrote:
> 
> I do tend to ramble on, so here's an executive summary of my response:
> 
> I want python developers to pay attention to the community buildbots and 
> to treat breakages of existing projects as a serious issue.

Counter-proposal:

* Interested developers or users of the major third party projects 
tested by the community buildbots should monitor the community 
buildbots, and start filing bug reports with the appropriate party as 
soon as the upcoming Python release hits 2.Xa1 (i.e. first alpha).

* If the failure is due to an incompatibility between Python 2.X and 
2.X-1, then the bug report should be filed against Python. While these 
issues may or may not be addressed before the first beta, they *must* be 
addressed before the first release candidate.

* If the failure is due to an incompatibility between Python 2.X and 
2.X-2 that was properly deprecated in 2.X-1, then the bug report should 
be filed against the third party project. Prioritising these is a 
question for the developers of that project.

* Before filing a bug report against Python for a community buildbot 
failure, check if the relevant regression is also causing failures of 
the core buildbots. If it is, skip the bug report until the core 
buildbots are passing again.

It's currently a fact of life that we do NOT keep the trunk in an 
always-releasable state. We just don't. It might be nice if we did, 
there are lots of reasons why that's a good way to run a project, but at 
this point in time it isn't the case with Python. Reacting every time a 
community buildbot goes red would be a serious waste of effort.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org