<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 3, 2016, at 10:17 AM, Barry Warsaw <<a href="mailto:barry@python.org" class="">barry@python.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Nov 03, 2016, at 12:54 AM, Nick Coghlan wrote:<br class=""><br class=""><blockquote type="cite" class="">This is also an area where I'm fine with recommending freemium<br class="">solutions if they're the lowest barrier to entry option for new users,<br class="">and "Use GitHub + Travis CI" qualifies on that front.<br class=""></blockquote><br class="">I won't rehash the GitHub/GitLab debate, but in some of my projects (hosted on<br class="">GH) I've had to ditch Travis because of limitations on that platform.<br class="">Specifically, I needed to run various tests on an exact specification of<br class="">various Ubuntu platforms, e.g. does X run on an up-to-date Ubuntu Y.Z?<br class=""><br class="">I originally used Docker for this, but our projects had additional<br class="">constraints, such as needing to bind-mount, which aren't supported on the<br class="">Travis+Docker platform. So we ended up ditching the Travis integration and<br class="">hooking our test suite into the Ubuntu autopkgtest system (which is nearly<br class="">identical to the Debian autopkgtest system but runs on Ubuntu infrastructure).<br class=""><br class="">Python may not be affected by similar constraints, but it is worth keeping in<br class="">mind. Travis isn't a perfect technical solution for all projects, but it may<br class="">be good enough for Python.<br class=""></div></div></blockquote></div><br class=""><div class="">I think phrasing this in terms of "perfect" and "good enough" presents a highly misleading framing. Examined in this fashion, of course we may reluctantly use the "good enough" option, but don't we want the <i class="">best</i> option?</div><div class=""><br class=""></div><div class="">A better way to look at it is cost vs. benefit.</div><div class=""><br class=""></div><div class="">How much does it cost you in terms of time and money to run and administer the full spectrum of "real" operating systems X.Z that you wish to support? How much does it cost in terms of waiting for all that extra build infrastructure to run all the time? How much additional confidence and assurance that it will work does that buy you, over the confidence of passing tests within a docker container? Is that additional confidence worth the investment of resources?</div><div class=""><br class=""></div><div class="">Of course, volunteer-driven projects are not concerned directly with top-level management allocation of ostensibly fungible resources, and so a hard "costly" solution that someone is interested in and committed to is far less expensive than a "cheap" solution that everyone finds boring, so we have to take that into account as well.</div><div class=""><br class=""></div><div class="">As it happens, Twisted has a massive investment in existing Buildbot CI infrastructure _as well as_ Travis and Appveyor. Travis and Appveyor address something that our CI can't, which is allowing unauthenticated builds from randos issuing their first pull requests. This gives contributors <i class="">much</i> faster feedback which is adequate for the majority of changes.</div><div class=""><br class=""></div><div class=""><div class="">However, many of our ancillary projects, which do not have as many platform-sensitive components, are built using Travis only, and that's a very good compromise for them. It has allowed us to maintain a much larger and more diverse ecosystem with a much smaller team than we used to be able to.</div></div><div class=""><br class=""></div><div class="">In the future, we may have to move to a different CI service, but I can tell you that <i class="">for sure</i> that 90% of the work involved in getting builds to run on Travis is transferrable to any platform that can run a shell script. There's a bit of YAML configuration we would need to replicate, and we might have to do some fancy dancing with Docker to get other ancillary services run on the backend in some other way, but I would not worry about vendor lock-in at all for this sort of service. Probably, the amount of time and energy on system maintenance that Travis saves us in a given <i class="">week</i> is enough to balance out all the possible future migration work.</div><div class=""><br class=""></div><div class="">-glyph</div></body></html>