On 7/5/2017 10:03 AM, Victor Stinner wrote:
2017-07-05 15:51 GMT+02:00 Victor Stinner :
Ok, since I spent weeks on fixing buildbots, I'm now more confident
that our buildbots are super stable. Since a test_datetime change
introduced a *regression* (ARMv7 started to
2017-07-05 15:51 GMT+02:00 Victor Stinner :
> Ok, since I spent weeks on fixing buildbots, I'm now more confident
> that our buildbots are super stable. Since a test_datetime change
> introduced a *regression* (ARMv7 started to fail), I reverted the
> first commit:
>
Ok, since I spent weeks on fixing buildbots, I'm now more confident
that our buildbots are super stable. Since a test_datetime change
introduced a *regression* (ARMv7 started to fail), I reverted the
first commit:
https://github.com/python/cpython/pull/2588
Again, it's not to reject the change,
On 15 June 2017 at 19:35, Nick Coghlan wrote:
> On 15 June 2017 at 00:40, Victor Stinner wrote:
>> A recent example is Nick Coghlan's implementation of the PEP 538:
>> basically, it broke all buildbots... except of Linux and Windows :-)
>> And it
On 17 June 2017 at 06:26, Brett Cannon wrote:
> On Fri, 16 Jun 2017 at 13:24 Ethan Furman wrote:
>> On 06/16/2017 09:48 AM, Brett Cannon wrote:
>> > Maybe we should amend PEP 11 to say that whomever volunteers to maintain
>> > a platform
>> > must make sure
On Fri, 16 Jun 2017 at 13:24 Ethan Furman wrote:
> On 06/16/2017 09:48 AM, Brett Cannon wrote:
>
> > Maybe we should amend PEP 11 to say that whomever volunteers to maintain
> a platform
> > must make sure that platform's buildbot is not red for longer than a
> month [...]
>
2017-06-16 10:37 GMT+02:00 Nick Coghlan :
> Hopefully reversions will continue to be rare (since relatively few
> changes are likely to be as platform dependent as PEP 538, and
> Windows/*nix differences are already covered in pre-merge CI), but
> when they do come up, the
On 15 June 2017 at 23:38, Victor Stinner wrote:
> 2017-06-15 5:31 GMT+02:00 Nick Coghlan :
>> For example, something that would be genuinely helpful would be a bot
>> monitoring PR comments that could automate the "custom-build" dance
>> for core
2017-06-15 5:31 GMT+02:00 Nick Coghlan :
> I'm not necessarily opposed to such a policy change, but if folks
> really want guaranteed green post-merge buildbots for all platforms
> (rather than just guaranteed green for Linux & Windows, sometimes red
> for everything else),
On Thu, 15 Jun 2017 13:31:39 +1000, Nick Coghlan wrote:
> On 15 June 2017 at 00:40, Victor Stinner wrote:
> > 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
> >
On 15 June 2017 at 00:40, Victor Stinner wrote:
> 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
On 15 June 2017 at 00:40, Victor Stinner 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
On Jun 14, 2017, at 11:00 PM, Victor Stinner wrote:
>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
On 06/14/2017 02:07 PM, Donald Stufft wrote:
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
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
2017-06-14 18:38 GMT+02:00 Serhiy Storchaka :
> 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.
On Wed, 14 Jun 2017 at 07:46 Victor Stinner
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
2017-06-14 18:38 GMT+02:00 Serhiy Storchaka :
>> What do you think? Would you be ok with such rule?
>
> 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.
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
19 matches
Mail list logo