[Python-Dev] Community buildbots and Python release quality metrics
Nick Coghlan
ncoghlan at gmail.com
Fri Jun 27 13:18:42 CEST 2008
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
More information about the Python-Dev
mailing list