Improving Contrib
Rich Hickey
to host Clojure development. The goal is to make it easier and more
desirable to work on the Clojure project, and encourage more libraries
to be developed within the project.
There are several impediments to people working in or on contrib, and
within the Clojure project. The community is obviously vibrant, as
there are many independent libraries. But fewer people work on Clojure
itself or on libraries intended for inclusion in Clojure. I'd like
that to change.
Although there have been recent efforts to make contrib more modular
from the Maven perspective (thanks Stuart Sierra!), it is still a
monolithic repo. Logically, the individual libs are more independent
than the repo structure would indicate. It should be much easier to
obtain, build, version, distribute, branch, test and modify individual
libraries.
Some of these problems flow from historical choices made by the
project. In particular, without money, boxes and the staff to maintain
machines on the net, I chose free project hosting service providers -
first SourceForge, then Google Code, and most recently GitHub and
Assembla. In all cases, there was a tension between project and user
management and code granularity. It would have been difficult to
manage the contrib libs as independent projects/repos.
Several things have changed recently that enable a better strategy.
GitHub has added an organization feature that lets us manage users at
the organization level and put multiple repos under the organization.
Contegix is donating a hosted box so we can run our own server (thanks
Contegix!), and the Clojure/core team now exists and is (voluntarily,
and among other things) providing much needed administrative support
(thanks Clojure/core team!).
The New Model
Contrib libraries will be independent repos under the Clojure GitHub
organization. All contributions to these libraries will be
contributions under the CA (therefor, no pulls). The primary authors
will have substantial independence in terms of versioning. branches
and releases etc, and it will be easy to obtain and work on a contrib
library a la carte.
We will be moving from Assembla to a self-hosted installation of the
Atlassian suite, which they generously make available for free to open
source projects (thanks Atlassian!). It will give us a superior wiki
and bug tracking system. We will initially have support for Jira,
Confluence and FishEye, and will be able to centrally manage users
with Crowd.
Individual contrib projects will get documentation and planning space
in the Confluence wiki, and a dedicated subproject in the Jira
tracking system.
Contrib is not a Standard Lib
People often ask if contrib constitutes a standard library. It has
always been a goal of contrib to support exploratory work of the
community that might or might not become part of Clojure proper, so
the simple answer is no. As volunteer open source efforts, each
library is likely to differ in quality, maturity and attention level.
In that respect, they don't differ from all of the other libraries on
GitHub. And with the new model, you will be using the same criteria in
evaluating a contrib library as you do any other open source library -
documentation, participation, recommendations, activity, stability,
bug reports etc. And you'll only consume as much of contrib as you
desire. Libraries will succeed on their merits. It is our plan to
reserve the 1.0.0+ designations for the more mature and widely
accepted libraries when they reach that point. That's as much
sanctioning as I anticipate for the near term.
You've Got to be In it to Win it
Why work within the Clojure project? Because you want your work to
eventually become part of Clojure and the Clojure distribution. You
want to tap into the core development effort and have an impact on it.
You are interested in collaborating on how best to make a set of
things work together in a coherent way, as Clojure does.
Isn't the GitHub free-for-all easier? Yes, but with this new setup,
only very slightly so. The easiest thing is not necessarily the best
thing. Participating in a project involves cooperation and compromise,
and stewardship implies responsibility.
Moving Forward
We will be working on getting the existing contrib libraries moved
over to the new model. Meanwhile, I'm happy to announce three new and
exciting contrib libraries that are kicking off the new model:
Chris Houser's Finger Tree - http://github.com/clojure/data.finger-tree
Chas Emerick's Network REPL - http://github.com/clojure/tools.nrepl
Michael Fogus's Unification Library - http://github.com/clojure/core.unify
These are terrific contributions, and good examples of things that
will have the greatest impact by being part of the Clojure project.
Thanks guys!
There are still some infrastructure things being worked out as regards
Confluence, Jira etc, and the Conj is keeping everyone busy at the
moment, but I expect this all to be in full swing shortly thereafter.
You can follow along here: http://dev.clojure.org/
I'm looking forward to seeing many of you at the Conj!
Rich
Chas Emerick
making this possible.
FYI, I'll be migrating the existing nREPL codebase from it's current
home (http://github.com/cemerick/nREPL) to the clojure organization
umbrella today or tomorrow. It's been a hectic week or two. :-)
- Chas
> Chas Emerick's Network REPL -http://github.com/clojure/tools.nrepl
> Michael Fogus's Unification Library -http://github.com/clojure/core.unify
Wilson MacGyver
to assume that most of these would be also uploaded by the creator into
clojars as new versions become available, thus using build tools like
mvn, gradle, lein,
etc to "pull them in" as we need them?
since I assume we are moving away from a monolithic zip file?
--
Omnem crede diem tibi diluxisse supremum.
Rich Hickey
On Oct 19, 12:04 pm, Wilson MacGyver <wmacgy...@gmail.com> wrote:
> How should we as users consume the libs under the new umbrella? Is it fair
> to assume that most of these would be also uploaded by the creator into
> clojars as new versions become available, thus using build tools like
> mvn, gradle, lein,
> etc to "pull them in" as we need them?
>
> since I assume we are moving away from a monolithic zip file?
>
infrastructure in general.
Rich
Luke Renn
management better than Maven does.
http://ant.apache.org/ivy/
http://ant.apache.org/ivy/features.html
Thanks,
Luke
Wilson MacGyver
you can pull from mvn repo using ivy, etc. I use gradle to pull both
the current clojure and clojure-contrib all the time.
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
Luke Renn
features. It's just maven without the 20 jars.
Luke
Mibu
participate in an open source project. I understand Rich Hickey and
most of you guys live in the litigious US and have to cover
yourselves, but I feel not right about this.
> Chas Emerick's Network REPL -http://github.com/clojure/tools.nrepl
> Michael Fogus's Unification Library -http://github.com/clojure/core.unify
Mike Meyer
Mibu <mibu.c...@gmail.com> wrote:
> The greatest impediment for me is having to sign a contract to
> participate in an open source project. I understand Rich Hickey and
> most of you guys live in the litigious US and have to cover
> yourselves, but I feel not right about this.
I've never run into a project - US-based or not - that required
this. At least not for reading the dev list or submitting patches.
If you don't trust the submitters to not sue you later, why do you
trust them to not check in back doors or time bombs?
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Rich Hickey
On Oct 19, 7:01 pm, Mike Meyer <mwm-keyword-googlegroups.
> > The greatest impediment for me is having to sign a contract to
> > participate in an open source project. I understand Rich Hickey and
> > most of you guys live in the litigious US and have to cover
> > yourselves, but I feel not right about this.
>
> I've never run into a project - US-based or not - that required
> this.
"The ASF desires that all contributors of ideas, code, or
documentation to the Apache projects complete, sign, and submit (via
postal mail, fax or email) an Individual Contributor License Agreement
(CLA) [PDF form]."
http://openjdk.java.net/contribute/
"Like many other open-source communities, the OpenJDK Community
requires contributors to jointly assign their copyright on contributed
code. If you haven't yet signed the Sun Contributor Agreement (SCA)
then please do so, scan it and e-mail the result to
sun_ca(at)sun.com."
http://forge.mysql.com/wiki/Contributing_Code
"If you expect to make code-related contributions, you must sign and
return the Oracle Contributor Agreement (OCA). Without an OCA on file,
Oracle cannot integrate your contribution into the MySQL code base or
engage in extended discussions on proposed patches."
https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft#FPCA_Text
http://contributing.openoffice.org/programming.html
http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright
http://framework.zend.com/wiki/display/ZFPROP/Contributor+License+Agreement
http://www.djangoproject.com/foundation/cla/faq/
http://nodejs.org/cla.html
http://www.10gen.com/contributor
etc.
Rich
Phil Hagelberg
> http://contributing.openoffice.org/programming.html
This is probably not a good example; the copyright assignment policy
for OpenOffice has caused the active contributors to fork it into
LibreOffice, which does not have such a policy:
-Phil
Sean Corfield
<mwm-keyword-goo...@mired.org> wrote:
> On Tue, 19 Oct 2010 15:51:17 -0700 (PDT)
> Mibu <mibu.c...@gmail.com> wrote:
>> The greatest impediment for me is having to sign a contract to
>> participate in an open source project. I understand Rich Hickey and
>> most of you guys live in the litigious US and have to cover
>> yourselves, but I feel not right about this.
> I've never run into a project - US-based or not - that required
> this. At least not for reading the dev list or submitting patches.
In my experience, it's pretty standard practice for any successful
open source project that expects to be used by large corporations.
I don't understand why anyone objects to them...?
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
Rich Hickey
On Oct 19, 7:38 pm, Phil Hagelberg <p...@hagelb.org> wrote:
> >http://contributing.openoffice.org/programming.html
>
> This is probably not a good example; the copyright assignment policy
> for OpenOffice has caused the active contributors to fork it into
> LibreOffice, which does not have such a policy:
>
>
That may be your take on it, but they worked under the Sun SCA for
quite a while. By all reports this fork seems more to be about
stewardship under Oracle and the rate of change. Now they are locked
into a license (the alternative to having CAs). They don't really have
an option, as they don't hold the original CAs. Taking CAs now for new
code wouldn't give them any more license flexibility, so it makes
sense that they don't bother.
Note here (http://keionline.org/ec-mysql) where Stallman himself
argues for the importance of license flexibility:
"There are fundamental and unavoidable legal obstacles to
combining code from programs licensed under the different GPL
versions."
"the lack of a more flexible license* for MySQL will present
considerable barriers to a new forked development path for MySQL"
I'd rather have CAs than be locked into a license. As the primary
author of the project, that's my choice, and these examples simply
show it's not an unusual or non-mainstream one.
Clojure's CA is a lose-nothing affair. It is not a copyright transfer,
contributors retain all the rights in their work. And it makes the
will-remain-open promise (which Sun was forced to add the their SCA
early on, due to community pressure). It is in fact that clause which
is preventing Oracle from taking the JDK (et al) closed moving
forward.
Yes, having a CA is a hurdle. Almost 200 people have managed to get
over it.
Rich
Mike Meyer
Rich Hickey <richh...@gmail.com> wrote:
>
>
> On Oct 19, 7:01 pm, Mike Meyer <mwm-keyword-googlegroups.
> 620...@mired.org> wrote:
> > On Tue, 19 Oct 2010 15:51:17 -0700 (PDT)
> >
> > Mibu <mibu.cloj...@gmail.com> wrote:
> > > The greatest impediment for me is having to sign a contract to
> > > participate in an open source project. I understand Rich Hickey and
> > > most of you guys live in the litigious US and have to cover
> > > yourselves, but I feel not right about this.
> >
> > I've never run into a project - US-based or not - that required
> > this.
>
> http://www.apache.org/licenses/
> http://openjdk.java.net/contribute/
> http://forge.mysql.com/wiki/Contributing_Code
> https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft#FPCA_Text
> http://contributing.openoffice.org/programming.html
> http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright
> http://framework.zend.com/wiki/display/ZFPROP/Contributor+License+Agreement
> http://www.djangoproject.com/foundation/cla/faq/
> http://nodejs.org/cla.html
> http://www.10gen.com/contributor
The ones I've checked or am familiar with apparently define
"contribute" differently than the clojure project does, in that they
allow you to both subscribe to the developer list(s) and submit bug
reports - including patches - without having to sign and post a
contributor agreement. Or maybe it's the clojure web site making
things difficult to find.
Nuts, I happened to apply for my Chickasaw Nation citizenship today -
which gives me tribal voting rights, free health care at tribal
hospitals and clinics, the ability to get grants for education,
housing, free laptops, etc, etc, etc. That was less work than being
allowed to submit a bug to the issue tracking system for clojure
(unless I just didn't find the right page....).
It was also more work than submitting patches looks to be for apache,
django, gnu, fedora, or openoffice (from your list, though it sounds
like openoffice may changed for the worse) or I know to be for
FreeBSD, PostreSQL, OpenSolaris, Python, Cheetah, to name some I've
been using for a while.
Sure, many of them require you to create an account to submit any bug
report. But that's straightforward, and a not unreasonable anti-spam
measure. Some even require you to click a checkbox assigning the
rights to anything you submit to the project in question as part of
that process. But I can still contribute patches to these projects
without having to print, sign and post any kind of developer
agreement.
Chas Emerick
On Oct 19, 7:55 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> On Tue, Oct 19, 2010 at 4:01 PM, Mike Meyer
>
> > On Tue, 19 Oct 2010 15:51:17 -0700 (PDT)
> > Mibu <mibu.cloj...@gmail.com> wrote:
> >> The greatest impediment for me is having to sign a contract to
> >> participate in an open source project. I understand Rich Hickey and
> >> most of you guys live in the litigious US and have to cover
> >> yourselves, but I feel not right about this.
> > I've never run into a project - US-based or not - that required
> > this. At least not for reading the dev list or submitting patches.
>
> In my experience, it's pretty standard practice for any successful
> open source project that expects to be used by large corporations.
>
> I don't understand why anyone objects to them...?
- If Apache and Sun/Oracle (along with a pile of others) do X w.r.t.
legalities, it seems prudent to follow suit as is practical.
- Barring that, do we really want to take even the smallest of
chances?
- Barring that, is not completion of the CA a reasonable a priori
proxy for the level of commitment of a contributor, where a base level
of commitment is desirable?
- Barring that, if the FSF's 20 lines (or whatever) is the threshold –
surely the size of a small bugfix – have we ever not patched a bug
because someone's small patch was rejected due to the lack of a CA?
Reporting a bug requires nothing.
- Barring that, assuming you're not a well-credentialed open source
lawyer, are you really comfortable second-guessing legal decisions
from afar?
Sorry for the rant.
I suggested in the channel sometime last month that a "Lodge your CA
here" table should be set up at the Conj. Anyone know if that's a go
or not? IMO, no one should leave on Saturday without being settled in
this department.
- Chas
Eric Schulte
> It was also more work than submitting patches looks to be for apache,
> django, gnu
FWIW in gnu projects if your patch is >10 lines long then they do
require you to go through a fairly lengthy attribution process.
http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html
Mike Meyer
Two things. First, the limit is "around 15 lines of code", excluding
repeated changes, and it applies over all patches, not just one:
http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
More importantly, this doesn't happen until *after* the patch has been
submitted and a contributor decides it should be included. Putting
roadblocks in front of people who want to submit patches or bugs - and
not being able to update the bug database qualifies, since you can't
report on the results of suggested fixes or at the very least add
another case to the existing ticket without a developer having to
notice the duplicate and flag it - is a bad idea.
Again, maybe it's possible to submit bugs to assembla without the CA;
but finding the assembla tickets list itself requires wading past the
verbiage about the CA. If bug reports (with or without patches)
doesn't require a CA, then it should be a lot easier to find.
Quzanti
but it inclusion in contrib did suggest to me that a library was being
widely used (and tested) and is relatively stable, and
that is there was a common problem, then contrib would likely have a
library for it
Then there is the convenience of just putting one jar on your
classpath.
Is the intention to make contrib more democratic and accessible, or to
get rid of the idea, in favour of letting people select their own
libraries?
> Chas Emerick's Network REPL -http://github.com/clojure/tools.nrepl
> Michael Fogus's Unification Library -http://github.com/clojure/core.unify
Stuart Halloway
I am excited by this thread and hope that the energy being shown here will translate into specific efforts to improve the colaboration process for everyone.
Stu
Sean Corfield
> I suggested in the channel sometime last month that a "Lodge your CA
> here" table should be set up at the Conj. Anyone know if that's a go
> or not? IMO, no one should leave on Saturday without being settled in
> this department.
I won't be at the Conj *sniff* because I'm on a roadtrip (currently in
ABQ, next stop LA) but this thread has inspired me to get a signed CA
to Rich as soon as I get back home!
Ulises
helping with contrib/etc.? I'm only starting to learn clojure but I've
found the community so helpful and thriving that I cannot help but to
want to help ... what is the first step?
U
Stuart Sierra
ataggart
being a stage for libraries which might get included into core. He
noted that having a set of libraries for which provenance is assured
is a strong selling point for getting clojure into certain types of
organizations, ones which otherwise might use clojure, but eschew the
notion of, say, needing to pull down random github code.
Amortized over the life of ones contributions, the hurdle of printing,
signing, and mailing one document is negligible, while the potential
rewards of an ever larger pool of clojure adoption is significant.
> Chas Emerick's Network REPL -http://github.com/clojure/tools.nrepl
> Michael Fogus's Unification Library -http://github.com/clojure/core.unify