[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

2020-10-19 Thread Brett Cannon
On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman  wrote:

> On 10/18/20 1:18 PM, Ned Deily wrote:
> > On Oct 18, 2020, at 15:45, Carol Willing  wrote:
> >> We've largely moved away from Travis for Jupyter testing in favor of
> Azure pipelines and CircleCI as Travis was becoming increasingly slow and
> timing out.
> >
> > Along those lines, if we are basically going to ignore the Travis CI
> results, perhaps we should consider being "good citizens" and stop running
> them all together.  Each PR change triggers multiple builds to run under
> Travis and all that extra and useless work contributes to the load on
> Travis and no doubt is not good for overall Travis responsiveness.
>
> If we have something else set up to takes its place that's fine;
> otherwise, let's leave it up with the understanding
> that we have to check it manually for success or failure -- that's still
> valuable information.
>

Unfortunately, the "valuable information" lately has been whether Travis is
even working. 😉

-Brett


> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/XAJE43CDSNJYMYJVQEZ7TSXB7FGW57YD/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/XZGDR7WYEIMKZAATYJFIQ5VX3ZKOOCMF/
Code of Conduct: https://www.python.org/psf/codeofconduct/


[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

2020-10-19 Thread Ned Deily
On Oct 19, 2020, at 13:59, Brett Cannon  wrote:
> On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman  wrote:
>> On 10/18/20 1:18 PM, Ned Deily wrote:
>> > On Oct 18, 2020, at 15:45, Carol Willing  wrote:
>> >> We've largely moved away from Travis for Jupyter testing in favor of 
>> >> Azure pipelines and CircleCI as Travis was becoming increasingly slow and 
>> >> timing out.
>> > 
>> > Along those lines, if we are basically going to ignore the Travis CI 
>> > results, perhaps we should consider being "good citizens" and stop running 
>> > them all together.  Each PR change triggers multiple builds to run under 
>> > Travis and all that extra and useless work contributes to the load on 
>> > Travis and no doubt is not good for overall Travis responsiveness.
>> 
>> If we have something else set up to takes its place that's fine; otherwise, 
>> let's leave it up with the understanding 
>> that we have to check it manually for success or failure -- that's still 
>> valuable information.
> Unfortunately, the "valuable information" lately has been whether Travis is 
> even working. 😉

Yes, and I still think it's unfair of us to use so much of Travis's resources - 
resources that other projects could use - when we are almost entirely ignoring 
the results.  On the master branch, each time a PR is merged or requires a CI 
run, we currently start up to 5 separate Travis jobs (some short-circuited but 
still jobs). The main job. which rebuilds python and runs the test suite, can 
run for 15+ minutes.  And then backports run some of the jobs as well.

Let's just disable Travis on all branches for now until there is reason to 
believe the problems we've seen are fixed.

--
  Ned Deily
  [email protected] -- []
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/AYLXEBIFHWCODJSIRS3W2C2HSQKHYRHM/
Code of Conduct: https://www.python.org/psf/codeofconduct/


[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

2020-10-19 Thread Brett Cannon
On Mon, Oct 19, 2020 at 11:22 AM Ned Deily  wrote:

> On Oct 19, 2020, at 13:59, Brett Cannon  wrote:
> > On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman  wrote:
> >> On 10/18/20 1:18 PM, Ned Deily wrote:
> >> > On Oct 18, 2020, at 15:45, Carol Willing  wrote:
> >> >> We've largely moved away from Travis for Jupyter testing in favor of
> Azure pipelines and CircleCI as Travis was becoming increasingly slow and
> timing out.
> >> >
> >> > Along those lines, if we are basically going to ignore the Travis CI
> results, perhaps we should consider being "good citizens" and stop running
> them all together.  Each PR change triggers multiple builds to run under
> Travis and all that extra and useless work contributes to the load on
> Travis and no doubt is not good for overall Travis responsiveness.
> >>
> >> If we have something else set up to takes its place that's fine;
> otherwise, let's leave it up with the understanding
> >> that we have to check it manually for success or failure -- that's
> still valuable information.
> > Unfortunately, the "valuable information" lately has been whether Travis
> is even working. 😉
>
> Yes, and I still think it's unfair of us to use so much of Travis's
> resources - resources that other projects could use - when we are almost
> entirely ignoring the results.  On the master branch, each time a PR is
> merged or requires a CI run, we currently start up to 5 separate Travis
> jobs (some short-circuited but still jobs). The main job. which rebuilds
> python and runs the test suite, can run for 15+ minutes.  And then
> backports run some of the jobs as well.
>

Yep, if Travis has limited their free resources then we are wasting them.
And without knowing where Travis gets their electricity there's even a
potentially (very slight) ecological cost from us wasting the runs. I am
with Ned about trying on to be wasteful here *just* *in case* Travs happens
to find something in a CI run.


>
> Let's just disable Travis on all branches for now until there is reason to
> believe the problems we've seen are fixed.
>

+1 from me.


>
> --
>   Ned Deily
>   [email protected] -- []
> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/AYLXEBIFHWCODJSIRS3W2C2HSQKHYRHM/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/IRHJ23U4AWODZFNWK3PCB2PDIRXAEQSB/
Code of Conduct: https://www.python.org/psf/codeofconduct/


[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

2020-10-19 Thread Ned Deily
On Oct 19, 2020, at 14:35, Brett Cannon  wrote:
> On Mon, Oct 19, 2020 at 11:22 AM Ned Deily  wrote:
>> On Oct 19, 2020, at 13:59, Brett Cannon  wrote:
>> > On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman  wrote:
>> >> On 10/18/20 1:18 PM, Ned Deily wrote:
>> >> > On Oct 18, 2020, at 15:45, Carol Willing  wrote:
>> >> >> We've largely moved away from Travis for Jupyter testing in favor of 
>> >> >> Azure pipelines and CircleCI as Travis was becoming increasingly slow 
>> >> >> and timing out.
>> >> > 
>> >> > Along those lines, if we are basically going to ignore the Travis CI 
>> >> > results, perhaps we should consider being "good citizens" and stop 
>> >> > running them all together.  Each PR change triggers multiple builds to 
>> >> > run under Travis and all that extra and useless work contributes to the 
>> >> > load on Travis and no doubt is not good for overall Travis 
>> >> > responsiveness.
>> >> 
>> >> If we have something else set up to takes its place that's fine; 
>> >> otherwise, let's leave it up with the understanding 
>> >> that we have to check it manually for success or failure -- that's still 
>> >> valuable information.
>> > Unfortunately, the "valuable information" lately has been whether Travis 
>> > is even working. 😉
>> Yes, and I still think it's unfair of us to use so much of Travis's 
>> resources - resources that other projects could use - when we are almost 
>> entirely ignoring the results.  On the master branch, each time a PR is 
>> merged or requires a CI run, we currently start up to 5 separate Travis jobs 
>> (some short-circuited but still jobs). The main job. which rebuilds python 
>> and runs the test suite, can run for 15+ minutes.  And then backports run 
>> some of the jobs as well.
>> 
> Yep, if Travis has limited their free resources then we are wasting them. And 
> without knowing where Travis gets their electricity there's even a 
> potentially (very slight) ecological cost from us wasting the runs. I am with 
> Ned about trying on to be wasteful here just in case Travs happens to find 
> something in a CI run.
>  
>> Let's just disable Travis on all branches for now until there is reason to 
>> believe the problems we've seen are fixed.
> +1 from me.


Pablo, Łukasz: any objections to disabling Travis on your branches?  If not, 
one of us, or Ernest, can just do it.

--
  Ned Deily
  [email protected] -- []
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/SSEJL7Q5NCZ7AX7VTBDQ2SDM7NL5SSF5/
Code of Conduct: https://www.python.org/psf/codeofconduct/


[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

2020-10-19 Thread Łukasz Langa

> On 19 Oct 2020, at 21:22, Ned Deily  wrote:
>>> Let's just disable Travis on all branches for now until there is reason to 
>>> believe the problems we've seen are fixed.
>> +1 from me.
> 
> Pablo, Łukasz: any objections to disabling Travis on your branches?  If not, 
> one of us, or Ernest, can just do it.

Absolutely, go ahead. In fact I see somebody already did. Good. Faster 
backports FTW.

- Ł___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/NSJHERYW4DOTPKSWOPX5OXNEDNAHHCXT/
Code of Conduct: https://www.python.org/psf/codeofconduct/