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

[Brett Cannon]

On Wed, 14 Jun 2017 at 07:46 Victor Stinner <victor.stinner at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170614/78bbd443/attachment-0001.html>