[EMAIL PROTECTED] 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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
