Hi all,

> On May 17, 2018, at 11:29 AM, Brett Cannon <br...@python.org 
> <mailto:br...@python.org>> wrote:
> 
> 
> 
> On Thu, 17 May 2018 at 12:57 Antoine Pitrou <solip...@pitrou.net 
> <mailto:solip...@pitrou.net>> wrote:
> 
> Hi Brett,
> 
> On Thu, 17 May 2018 10:54:27 -0400
> Brett Cannon <br...@python.org <mailto: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 
> <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 
> <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 
> <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 
> <mailto:core-workflow@python.org>
> To unsubscribe send an email to core-workflow-le...@python.org 
> <mailto:core-workflow-le...@python.org>
> https://mail.python.org/mm3/mailman3/lists/core-workflow.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

Reply via email to