On Thu, 17 May 2018 at 11:41 Guido van Rossum <gu...@python.org> wrote:
> Hm... While I'm grateful for the donation, this sounds a bit like a coup.
> It looks as if MS trying to poach reference customers (like the
> well-respected CPython project) from AppVeyor and Travis-CI.
This was an idea from Steve and me, not the VSTS team. I'll also mention
that while we get some extra builders from Travis we get nothing special
> Those are two small companies that have donated a lot of resources to many
> open source projects, and are also dependent on those open source projects
> as reference customers so they can sell to paying customers.
> I'm sure Brett and Steve are doing this for Python, but just remember
> there's no such thing as a free lunch. Who pays for those 20 machines?
> Is it coming out of MS's PR and marketing budget?
The extra credits are coming from VSTS itself (there is also the base free
credits that anyone can get, so this whole thing isn't special to us). VSTS
asked if we knew of any projects that might be interested in being involved
in the preview, Steve and I said we were since we wanted the better
performance for CPython, we then asked if we could have extra credits and
they said sure, and here we are. IOW no one is pushing anything on us,
we're proactively asking for this ourselves to address performance
complaints I have received since our transition to GitHub due to Travis and
AppVeyor taking a while to queue up builds for us (to the point that we
don't depend on macOS builds because they historically take too long).
And If people feel I'm not impartial enough then I'm fine with someone else
making the decision to either leave around or turn off Travis and AppVeyor
(Steve is already purposefully staying out of the final decision). As I
said, I just know we have needed to put time into keeping Travis and
AppVeyor happy so I figured if we ended up being happy with VSTS we would
want to keep things simple.
I'll also not quite sure why this is different than the credits we get from
e.g. Heroku/Salesforce for the bots or AWS for PyPI? I get the worry of
relying on a company that's too big to care if they upset us, but we
already do rely on such companies so if this is to be a new policy then we
have some de-tangling to do.
And I do understand the worry if this was old MS, but this is new MS (i.e.
the one I choose to work for ;) . I have been in multiple meetings with VPs
who were worried about upsetting the open source community and I had to
step in and tell them that they were worrying too much. :)
IOW no one has done or is doing a sales pitch here; Steve and I just saw an
opportunity to address a problem I have seen with our CI and so we decided
to go for it with me being optimistic it's going to pay off. I apologize if
people think we are overstepping, but honestly we're just excited to get
faster CI and to actually measure the impact we have to do the initial
integration and my excitement has made be see the bright side of life for
> On Thu, May 17, 2018 at 7:54 AM, 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).
>> Basically Steve Dower and I have been working directly with the VSTS team
>> to improve their Python support. Along the way they have announced they are
>> adding anonymous access to build logs which was always a major blocker for
>> using it in open source. VSTS gave us early access to the anonymous access
>> that they are launching along with 20 concurrent builders which is more
>> than what we currently have on Travis and AppVeyor.
>> At this point Steve has added the appropriate YAML files in the .vsts
>> directory that control the build jobs so we can test out the integration
>> and see what the performance is like. But based on what we have been seeing
>> there will be no queue in getting PRs tested and that applies to Windows,
>> macOS, and Linux (IOW better coverage and no more issues about performance
>> or having to wait too long for CI to go green ;) . There is also other
>> benefits like making at least Windows builds easier to release as signing
>> those builds can now be automated.
>> My expectation is that once we are convinced that the VSTS builds are
>> passing consistently and everything is working as everyone wants for e.g. a
>> week, we can plan to turn off Travis and AppVeyor for master and 3.x
>> branches (no one wants to bother with trying to get 2.7 to work on this and
>> we can simply continue to rely on Travis and AppVeyor as necessary for the
>> next 18 months). I don't think we want to run multiple CIs indefinitely on
>> the same branch as it does take time and effort to keep CI green on a
>> provider since they all have their own quirks.
>> I should also mention that this free access is not limited to just
>> CPython and any project can get free accounts and credits now, you just
>> have to talk to Steve about getting in on the anonymous access before it
>> launches to the general public (I have no timeline on when that's
>> core-workflow mailing list -- email@example.com
>> To unsubscribe send an email to core-workflow-le...@python.org
>> This list is governed by the PSF Code of Conduct:
> --Guido van Rossum (python.org/~guido)
core-workflow mailing list -- firstname.lastname@example.org
To unsubscribe send an email to core-workflow-le...@python.org
This list is governed by the PSF Code of Conduct: