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

Guido van Rossum guido at python.org
Thu Jun 26 23:17:02 CEST 2008


On Thu, Jun 26, 2008 at 12:35 PM,  <glyph at divmod.com> wrote:
>
> On 05:14 pm, martin at v.loewis.de wrote:
>>>
>>> I don't know.  JP is already addressing the issues affecting Twisted in
>>> another thread (incompatible changes in the private-but-necessary-to-
>>> get-any-testing-done API of the warnings module).  But I really think
>>> that whoever made the change which broke it should be the one
>>> investigating it, not me.
>>
>> How could they have known that they broke it?
>
> Because the relevant community buildbot turned red with that revision of
> trunk.  Keep in mind I'm not talking about every piece of Python code in the
> universe; just the ones selected for the community buildbots.  It would be
> nice if there were a dozen or so projects on there, but paying attention to
> the two builders that do actually run right now would be a good start.

Sorry, this is an unacceptable burden on the core developers. The core
developers aren't going to look at the community buildbots (unless
voluntarily) and they aren't going to roll back changes just because
some community buildbot goes red.

In general someone outside the core developer group needs to bring the
issue to the core developers' attention and then a fix will be created
if appropriate. Rollbacks are generally reserved for accidental
checkins or checkins against the process rules (e.g. during a code
freeze). Heck, we don't even roll back if one of our own buildbots
goes red.

I'm fine with requesting that the core developers pay serious
attention to reports about 3rd party code being broken. The community
buildbots are a fine tool to find out about this. But any policy that
requires an automatic rollback because a buildbot (community or core)
goes red is unacceptable.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list