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
