On Wed, 14 Jun 2017 at 07:46 Victor Stinner <victor.stin...@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/ >
_______________________________________________ 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/