On Sat, Mar 28, 2015 at 9:34 PM Peter Ansell <[email protected]> wrote:
> 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 think this is the most troubling part of your post from my point of view. One of the things we need to be extremely careful about in the incubation process isn't the fact that people are consumed with the Apache brand. If the goals here are simply to get the name Apache put in front of the project, it's probably not going to grow that well. While it is true there are many services out there to leverage, we're expected to use Apache services. That doesn't mean solely Apache services. You can use Travis, Coveralls, Cloudbees, GitHub wiki, etc all you want. One limitation we do have is that you can't download binaries from those sites that don't point to an Apache mirror'd location. > > > 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 >
