On 29/03/15 23:57, Peter Ansell wrote:
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
For me personally, I see the move to Apache as giving the project long
term (e.g. 10 year) stability separate from github (a commercial company
that might change at any time (unlikely, but then FoundationDB was a big
surprise), and separate from specific people.
Any long term OS project needs to have a governance structure. Many
have their own foundations; that's a big overhead for small(er)
projects. ASF provides assurance that the IP is setup correctly. IP,
and legal issues generally, seem a burden at times but if done right
initially then everything runs smoothly. Unlike code, going back and
trying to fix an early problem is much harder in legal.
I think using all the tools around to improve the output of this
activity is good. ASF infrastructure and process first and foremost
insures the integrity of releases (source and binary). The development
assist is very useful as well. As a small activity, many different ways
of doing that work for us.
Branding the technology is, for me, not a significant part of the move.
> Apache didn't have any
> control measures around binaries
A community can define what it agrees over and above the minimum at
Apache and Java makes it somewhat different to the C world. Any
binaries in a release process must correspond to the source which is
what one would expect of any OS project. Publishing to maven is part of
the release process for Java projects.
(I also find some of the language around releases vs snapshots too
extreme as well. It seems to reinforce an artificial barrier between
user@ and dev@ for the Java world which is not where it's at.)
Andy
