On 29 March 2015 at 11:57, John D. Ament <[email protected]> wrote: > Great question/comment! I always look forward to this part with new > podlings. > > On Sat, Mar 28, 2015 at 5:32 PM Peter Ansell <[email protected]> wrote: > >> That is fine with me. >> >> I am not overly fascinated by internal Apache infrastructure though so >> I would like to keep the .travis.yml file and the references to >> coveralls if possible as there is nothing broken with that system >> right now for CI and code coverage. >> > > It's weird that you feel this way (from my point of view). Part of why > projects seek out the ASF is to leverage the infrastructure in place that's > provided. It's generally expected that the in house services will be > leveraged. > > http://www.apache.org/dev/services.html
That perspective is very reduced these days by the free set of services that non-Apache projects generally rely on these days. Ie, a project can (and virtually all of my other projects that I am active with do so) run quite comfortably just with free (for open source code) providers: * GitHub or BitBucket for code hosting, wiki * GitHub for HTTP hosting and possibly issue tracking * Free Jira issue tracking license and hosting on Atlassian Cloud/OnDemand for OSS projects * TravisCI for continuous integration * Sonatype OSS Nexus repositories for snapshots and releases * Coveralls for code coverage * Google Groups for mailing lists In reality, the main reasoning for going to Apache is probably solely the brand these days, which overcomes the administrative overhead in the case of mature projects, or in our case, fairly short-lived projects (in terms of active development, we want to maintain a consistent core after a short term of stabilisation). > I would expect that projects that come in through the incubator will > leverage the ASF Jenkins instances over external builders. It's fine to > have external builders, but the official CI for the project would be ASF > Jenkins. For example, Travis can't deploy to the nexus instances for > snapshots. Yes, the requirement to deploy our future artifacts to Maven Central through the Apache Nexus instances (not Sonatype OSSRH Snapshots/Release like non-Apache projects do, and we have done so far), is a reasonable reason for setting up a Jenkins instance. However, it doesn't invalidate the much simpler to configure and use Travis service, even if we don't deploy snapshots through it. If anything, it will highlight when the Jenkins configuration is broken, as it most often is when a random bug surfaces that hasn't appeared on development computers. All that supporting Travis and Coveralls into the future will require is for an admin to setup the TravisCI hook on the GitHub repository, as has been done in the past for other projects: https://issues.apache.org/jira/browse/INFRA-7096 Ie, the system is already working with https://github.com/commons-rdf/commons-rdf, we just need the same hook setup for https://github.com/apache/incubator-commonsrdf Cheers, Peter
