couchdb-dev mailing list archives

On Fri, Aug 14, 2009 at 6:43 AM, Noah Slater<nslater@apache.org> wrote:
> On Fri, Aug 14, 2009 at 03:37:01PM +0800, J Aaron Farr wrote:
>> Just to give you a heads up, the ASF has had rather mixed results with
>> subprojects and we've specifically tried to avoid what's been termed as
>> "umbrella projects." Jakarta is/was the poster child example.
>
> Thanks for the feedback.
>
> I think that we have a lot to learn from Django about selection here:
>
> http://jacobian.org/writing/what-is-django-contrib/
>
> Just to summarise in quotes:
>
> "contrib packages should be removable."
>
> "anything in contrib needs to be generally accepted as the Right Way to do
> something for a large majority of users."
>
> "contrib packages should solve problems encountered frequently by real-world
> web developers."
>
> "Good contrib packages tackle issues that that are not trivial, are bikeshed
> prone, and are difficult to get right for the common case. We want to prevent
> folks from needing to decide among seventeen different session frameworks, for
> example."
>
> "there’s a danger in bringing something into the core: it stifles future
> innovation. As soon as we “bless” a contrib package, we drastically reduce
> impetus to write competing libraries. So, a good contrib package should have
> general consensus, and should be fairly mature."
>
> Would we need to adopt the same thinking?
I generally agree with those principles, although I think we can get
away with being informal about them at least at first.
For instance, I don't think it would serve well to make CouchRest or
other client-library code a subproject. If we find that subproject
organization does help a lot, then maybe Futon would make sense as a
subproject, but I'm not in a rush.
I'd be happy to give subproject developers full commit access, and
trust them to know their limits around things like the storage engine,
etc.
As far as calling them projects vs some other word, I'm not really
concerned about labeling, but other Apache projects use the word
sub-project and that seems to make it clear what they mean. Generally
I think getting both the community and the code for a few of these
core projects under one roof seems like the win to me.
>
> Would be throw the doors wide open and let any project be a sub-project?
>
> What about competing sub-projects, doing the same thing?
>
> I think we need to discuss this, and get the policy nailed first.
>
>> I'm not saying couchdb can't organize itself into subproject, but I do
>> want to give you a heads up about the sort of subproject politics you
>> can bump into down the road. For example, a clear warning sign is when
>> you start giving out commit rights to only certain subprojects.
>
> I don't understand this point.
>
> Why would any sub-project NOT have commit rights?
>
> Or did you mean, only letting certain projects be official sub-projects?
>
> I would have thought the latter is a requirement!
>
> Thanks,
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
--
Chris Anderson
http://jchrisa.net
http://couch.io