On Wed, 14 Jun 2017 at 07:46 Victor Stinner <victor.stinner@gmail.com> wrote:
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.

There's also macOS if you look at the Travis results manually.
 

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?

I'm +1 on it. We have always expected people to watch the buildbots after a commit to make sure nothing horrible happened. And leaving a branch broken just makes fixing it harder due to code change and it masks potential failures from subsequent commits that happen to manifest themselves as a similar failure.

-Brett
 

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
_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/