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

2017-06-15 Thread Nick Coghlan
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'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 ;-)

Status update on this specific change: Mac OS X should be back to
green now [1] (with some anomalous cases being skipped [2])

The tests are currently still failing on C-locale-only platforms (see
[3]), and on FreeBSD specifically (see [4])

Cheers,
Nick.

[1] http://buildbot.python.org/all/builders/x86%20Tiger%20custom/builds/7
[2] https://bugs.python.org/issue30672
[3] https://bugs.python.org/issue30565#msg296006
[4] https://bugs.python.org/issue30647

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


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

2017-06-15 Thread R. David Murray
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 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 place to focus effort
> would be in making it easier for us to test things across the full
> BuildBot fleet in pre-merge CI.

I've long thought that reversion should be the policy.

I'm all in favor of making it easier to run the custom builders on a PR,
of course, but I think the policy change is orthogonal to that.  It's not
like that change represents effort that would otherwise be devoted to
making using the custom build easier...Victor is putting out the effort
to monitor the buildbots already and clearly intends to continue to do
so regardless.  Being able to revert will make the job he has taken on
(thank you Victor!) easier.

--David
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


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

2017-06-15 Thread Victor Stinner
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 place to focus effort
> would be in making it easier for us to test things across the full
> BuildBot fleet in pre-merge CI.
>
> 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 like
> "BuildBot: test custom build", and it would go away, kick off a custom
> BuildBot run by pushing the PR to the "custom-build" branch, and then
> report back the links for failed builds like
> http://buildbot.python.org/all/builders/x86%20Tiger%20custom/builds/5
> )

I don't think that buildbots have enough resources to run tests on
each PR. We get too many PR and each PR is updated regulary. On some
buildbots, a single build can take 1 hour (or longer)... Moreover,
that's an idea, but we need "someone" to do the job. I don't know
anyone available to do it.

I'm proposing a pragmatic solution to a concrete issue. I'm just to do
by best with our limited resources (human and CPU time). Again,
failures on random platforms not catched by our pre-commit CI occur,
but are -hopefully- rare!

I dislike having a long list of "nice to have" list for our infra. I
prefer to focus on the existing bricks and don't put too much pressure
on people who give their time to care of our tooling and infra ;-)

(Yes, I would also prefer to have a fleet of buildbots at the
pre-commit stage if I can get it for free :-))

Victor
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


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

2017-06-15 Thread Brett Cannon
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, sometimes red
> > for everything else), then I think a better place to focus effort
> > would be in making it easier for us to test things across the full
> > BuildBot fleet in pre-merge CI.
> >
> > 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 like
> > "BuildBot: test custom build", and it would go away, kick off a custom
> > BuildBot run by pushing the PR to the "custom-build" branch, and then
> > report back the links for failed builds like
> > http://buildbot.python.org/all/builders/x86%20Tiger%20custom/builds/5
> > )
>
> I don't think that buildbots have enough resources to run tests on
> each PR. We get too many PR and each PR is updated regularly. On some
> buildbots, a single build can take 1 hour (or longer)... Moreover,
> that's an idea, but we need "someone" to do the job. I don't know
> anyone available to do it.
>
> I'm proposing a pragmatic solution to a concrete issue. I'm just to do
> by best with our limited resources (human and CPU time). Again,
> failures on random platforms not caught by our pre-commit CI occur,
> but are -hopefully- rare!
>
> I dislike having a long list of "nice to have" list for our infra. I
> prefer to focus on the existing bricks and don't put too much pressure
> on people who give their time to care of our tooling and infra ;-)
>

I at least appreciate that. :)


>
> (Yes, I would also prefer to have a fleet of buildbots at the
> pre-commit stage if I can get it for free :-))
>

Yes, that would definitely be nice, especially if we could get it working
in the cloud to handle load and a wider range of OSs. But this is all
orthogonal to the question of "revert immediately or not?". It's also not
worth discussing here as it's totally wishful thinking for the foreseeable
future (that's what the core-workflow issue tracker is for ;) .

-Brett


>
> Victor
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Promote Julien Palards as Committers on docsbuild-scripts

2017-06-15 Thread Brett Cannon
I've made Python core able to read the buildmaster-config repo.

On Wed, 14 Jun 2017 at 13:53 Victor Stinner 
wrote:

> 2017-06-14 22:40 GMT+02:00 Brett Cannon :
> >> Oh, I didn't know. Is it possible to see who owns a GitHub Python
> project
> >> at https://github.com/python/?
> >
> > If you can see
> https://github.com/orgs/python/teams/python-core/repositories
> > then yes. :)
>
> About this list, there was a question on the buildmaster-config
> repository. Mariatta Wijaya's message:
> """
> I didn't know about buildmaster-config repo.
>
> It's not listed as one of the projects for the Python Core team :)
>
> https://github.com/orgs/python/teams/python-core/repositories
>
> Should it be?
> """
>
> http://bugs.python.org/issue30658#msg296018
>
> Victor
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Promote Julien Palards as Committers on docsbuild-scripts

2017-06-15 Thread Victor Stinner
Oh nice, thanks to your change, it's now listed in the list!
https://github.com/orgs/python/teams/python-core/repositories

Victor

2017-06-15 22:40 GMT+02:00 Brett Cannon :
> I've made Python core able to read the buildmaster-config repo.
>
> On Wed, 14 Jun 2017 at 13:53 Victor Stinner 
> wrote:
>>
>> 2017-06-14 22:40 GMT+02:00 Brett Cannon :
>> >> Oh, I didn't know. Is it possible to see who owns a GitHub Python
>> >> project
>> >> at https://github.com/python/?
>> >
>> > If you can see
>> > https://github.com/orgs/python/teams/python-core/repositories
>> > then yes. :)
>>
>> About this list, there was a question on the buildmaster-config
>> repository. Mariatta Wijaya's message:
>> """
>> I didn't know about buildmaster-config repo.
>>
>> It's not listed as one of the projects for the Python Core team :)
>>
>> https://github.com/orgs/python/teams/python-core/repositories
>>
>> Should it be?
>> """
>>
>> http://bugs.python.org/issue30658#msg296018
>>
>> Victor
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/