OK, clearly I worry too much. :-)

Faster tests are certainly most welcome, and I am super grateful for all
the work that Steve and Brett have put into this.

--Guido

On Thu, May 17, 2018 at 3:41 PM, Carol Willing <
willi...@willingconsulting.com> wrote:

> Hi all,
>
> On May 17, 2018, at 11:29 AM, Brett Cannon <br...@python.org> wrote:
>
>
>
> On Thu, 17 May 2018 at 12:57 Antoine Pitrou <solip...@pitrou.net> wrote:
>
>>
>> Hi Brett,
>>
>> On Thu, 17 May 2018 10:54:27 -0400
>> Brett Cannon <br...@python.org> wrote:
>> > Since both Paul Moore and Antoine Pitrou started to ask questions about
>> a
>> > side comment I made about VSTS, I might as well start a discussion
>> (Steve
>> > has also *just* emailed python-committers about this topic).
>>
>> The main thing that worries me is that VSTS (the service, perhaps not
>> the basic infrastructure) is a very new thing and we don't have any
>> visibility over its continuity, its capacity, its robustness, etc.
>>
>
> Actually, depending on how you measure, VSTS is older than Travis. :) So
> originally there was TFS which was an on-premise thing from MS released in
> 2005 (https://en.wikipedia.org/wiki/Team_Foundation_Server). The
> cloud-hosted version is VSTS and that was released in 2013 (
> https://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Team_Services).
> Travis it turns out was founded in 2011 (https://en.wikipedia.org/
> wiki/Travis_CI).
>
> And if it makes you feel any better, all of MS runs on VSTS, e.g. Windows,
> Visual Studio, Office, etc. So it's only "new" from the perspective of
> anonymous access and thus being usable for open source projects in general.
>
>
>> Travis-CI and AppVeyor, with all their defaults, have been in this
>> space for some time, have a lot of existing customers and we can expect
>> some amount of stability in the future (of course, there's no
>> guarantee).
>>
>> So I'd like it if didn't ditch *all* of the non-VSTS CI.  Not for now
>> anyway, we can of course revisit the decision in 2 years :-)
>>
>
> If that's how people end up feeling in general then that's fine and we can
> leave Travis and/or AppVeyor in place and simply not make them required so
> they don't hold us up if VSTS turns out to run faster.
>
>
> I had a long discussion with Steve at PyCon about VSTS. The benefits seem
> promising.
>
> Perhaps a reasonable step forward is to run Travis, AppVeyor, and VSTS as
> required for 3 months or 6 months. This would give everyone a view into
> using VSTS.
>
> After the initial period, we could then revisit what makes sense in the
> longer term. Which could be to continue using and requiring all; use all
> but perhaps relax the requirement for passing; or to choose one preferred
> combination of tools.
>
>
>
> _______________________________________________
> core-workflow mailing list -- core-workflow@python.org
> To unsubscribe send an email to core-workflow-le...@python.org
> https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
>
>
> _______________________________________________
> core-workflow mailing list -- core-workflow@python.org
> To unsubscribe send an email to core-workflow-le...@python.org
> https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
>


-- 
--Guido van Rossum (python.org/~guido)
_______________________________________________
core-workflow mailing list -- core-workflow@python.org
To unsubscribe send an email to core-workflow-le...@python.org
https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Reply via email to