couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Apache sub-projects
Date Fri, 14 Aug 2009 13:43:27 GMT
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?

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

Mime
View raw message