I’m +1 on reverting the change, I’d even go so far to say I’d be +1 on doing it as a first response. It’s always possible to revert the revert once the person who committed the patch has time to investigate the failure and recommit the patch with a fix.

On Jun 14, 2017, at 5:00 PM, Victor Stinner <victor.stinner@gmail.com> wrote:

2017-06-14 18:38 GMT+02:00 Serhiy Storchaka <storchaka@gmail.com>:
I think we first should make buildbots notifying the author of a
commit that broke tests or building, so his can either quickly fix the
failure or revert his commit.

Hum, I think that I should elaborate my previous email.

It's usually easy to identify a commit which introduced regressions if
you compare 2 or 3 failing buildbots and their list of changes. So
when I identify the commit, if I cannot fix the issue immediately,
usually I leave a message on the issue (bugs.python.org). So the
author but also other people who worked on the issue are well aware of
the regression.

In my experiemnce, it's rare that I get any feedback in less than 24h,
while slowly more and more buildbots become red. It depends on the
availability of the commiter.

Since I'm trying to always keep the highest number of green buildbots,
I prefer to try to fix the bug myself.

My question is what to do if I'm unable to fix the issue and the
author is not available. Keep a broken CI for hours, sometimes for
days. Or revert the change to reduce the pressure and get more time to
write a *proper* fix?

I propose to revert to get more people at the issue to find the best
option, rather than urging to push a quick & dirty fix.

Hopefully, in most cases, the bug is trivial and I consider that the
fix doesn't require a review, so I push it directly.

python-committers mailing list
Code of Conduct: https://www.python.org/psf/codeofconduct/

Donald Stufft