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
