[python-committers] Revert changes which break too many buildbots

[Victor Stinner]

Hi,

The CPython workflow was enhanced to get pre-commit CI checks. That's
a huge win, thank you for that... But, sometimes, a change can still
break many buildbots, bugs which weren't catched by pre-commit checks
(Travis CI/Linux and AppVeyor/Windows). Buildbots cover much more
different architectures and platforms.

I spend a significant amount of time to maintain the sanity of our
buildbots. Sometimes, it can take me up to 3 days on a week (of 5
working days). It's annoying to see new regressions while I'm trying
hard to fix old ones :-(

So I would like to set a new rule: if I'm unable to fix buildbots
failures caused by a recent change quickly (say, in less than 2
hours), I propose to revert the change.

It doesn't mean that the commit is bad and must not be merged ever.
No. It would just mean that we need time to work on fixing the issue,
and it shouldn't impact other pending changes, to keep a sane master
branch.

What do you think? Would you be ok with such rule?

A recent example is Nick Coghlan's implementation of the PEP 538:
basically, it broke all buildbots... except of Linux and Windows :-)
And it will take a few more days to fix all failures. Well, we are
working on fixing these issues, so I don't want to revert this change.
It's just an example of a single change which broke many buildbots.
The PEP 538 depends a lot on the platform, so I'm not surprised to see
different failures per platforms ;-)

By "buildbot failure", I mean a red buildbot failing because of
compilation error or failed test suite. But I would prefer to ignore
failures of the Refleak buildbots since these ones are not stable
(even if there are less and less ref leaks in master, and these
buildbots already catched recent regressions!).

If the rule is approved, I plan to announce it on python-dev to be transparent.

Victor