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 fail), I reverted the
first co
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:
> https://github.com/python/cpyth
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, ju
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 will take a few more days to fix all failures. Wel
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 that platform's buildbot is not red fo
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 [...]
>
> How about three?
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
[...]
How about three? Some life changes need more than a month to recover from... (de
On Fri, 16 Jun 2017 at 03:40 Victor Stinner
wrote:
> 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 C
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 reminder of how to manual
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 developers (i.e. we'd be able to write something li
On Thu, 15 Jun 2017 at 06:39 Victor Stinner
wrote:
> 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, s
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), then I think a better pl
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
> > hours), I propose to revert the change.
>
> I'm
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 fixing these issues, so I don
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
> (Travis CI/Linux and AppV
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 fo
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 Sti
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.
It's usually easy to id
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 checks
> (Travis CI/Linux and
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.
One or two months ago, I
2017-06-14 17:40 GMT+03:00 Victor Stinner :
> 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. I
22 matches
Mail list logo
