On 30 March 2015 at 06:10, John D. Ament <[email protected]> wrote: > 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.
We don't expect a community to grow around the code itself, which was part of the reason for wanting it to be located within the broader Commons community in preference to a TLP. The reasoning is that there will be minimal changes to the APIs which make up the code, once it is stabilised, by design. Other than the pure Java interfaces which make up the API, we only have a single implementation that we will be developing against it. The only reasoning for having the simple implementation is to check the contract tests against a system that has no dependencies and is produced for the sole purpose of being a test harness. Given its status as a test harness, it doesn't need to be optimised, but it does need to fulfill the contracts, so if the contracts change, the test harness will need to reflect the change. Once the contracts are finalised, the simple implementation will be basically as static as the APIs. Part of the reasoning for starting out on GitHub was to attract a broad initial discussion, which, before we had a dedicated mailing list here, wasn't as simple as GitHub Issues and PRs for collaboration and quick commenting on the overall design. Since everyone has GitHub accounts, but not everyone wanted to subscribe to the deluge of emails going through the commons dev mailing list, it was the logical solution for the initial discussion. In addition, we had two approaches to the commons community last year but both seemed to fail during negotiation on the point that we required a dedicated mailing list inside of the Commons TLP, which is why we ended up here in the Incubator, essentially. I am personally ambivalent to whether this project is hosted within Apache, to gain the brand recognition, or whether it exists on GitHub as an independent project there, but the other main contributors heavily favour Apache and are fine with handling the administrative overhead that comes with that choice. > 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. That sounds fine, although I thought that Apache didn't have any control measures around binaries, with all releases only formally containing the source, with the binaries incidental? We will be using Maven Central as the main point of access for downloads, so that should be fine, given that every other Apache Java project also does that. Cheers, Peter
