couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shaun Lindsay <>
Subject Re: Apache sub-projects
Date Fri, 14 Aug 2009 20:59:10 GMT
I'd be excited to see couchdb-lounge make it in as a subproject, especially
if the overall goal is to incorporate features from the lounge directly in
to CouchDB.  Making it a subproject seems like a good intermediate step in
that direction.

On Fri, Aug 14, 2009 at 11:34 AM, Chris Anderson <> wrote:

> On Fri, Aug 14, 2009 at 10:19 AM, Noah Slater<> wrote:
> > On Fri, Aug 14, 2009 at 09:55:34AM -0700, Chris Anderson wrote:
> >> I generally agree with those principles, although I think we can get
> >> away with being informal about them at least at first.
> >
> > Creating a project as a sub-project of Apache CouchDB is a necessarily
> formal
> > affair, and on that we can't easily go back on without a lot of pain.
> Blessing
> > something as a sub-project will have massive implications for the
> community
> > around it, and around CouchDB proper.
> >
> > While I think there is some obvious value to be found here, like with
> Django, I
> > think that we need to think about this seriously before we accept any
> projects.
> > If if we decide on a criteria for inclusion at some future point, that
> excludes
> > some existing sub-projects because we were in a rush to add them, then we
> are
> > going to have a bit of an awkward problem on our hands.
> >
> > Does the ASF have any guidelines for this?
> >
> > Is there any ASF lore that we can fall back on for guidance here?
> I think a shared understanding of our values around subprojects (and
> more generally) is important. But I'd be quite happy to bring in
> sub-projects on an ad-hoc basis.
> So often it is a mix of the people, the code, and circumstance that
> makes one project stand out for inclusion. Trying to apply the same
> reasoning when bringing in all/any sub-projects doesn't seem
> necessarily productive. I *do* agree with you that we should talk
> about how to make the decision to bring on a sub-project. I just think
> that we should treat them on a project by project basis.
> I liked the Django quotes you posted. I'm pasting them again here:
> ==
> I think that we have a lot to learn from Django about selection here:
> 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?
> > --
> > Noah Slater,
> >
> One thing all the projects we've mentioned have in common is a
> polyglot of languages. I think it will be healthy for CouchDB to have
> a few languages represented in the distribution.
> Now that I think about it, QueryServers might make a good sub-project.
> It would be a good way to involve people from the Erlang / Ruby /
> Python, etc communities to contribute to CouchDB. Now that we have a
> test suite for query servers we can afford to keep contrib versions of
> them in more than one or two languages. I'm not proposing we refactor
> this out immediately, but it's the direction I can see sub-projects
> going.
> I'd love to hear what other people think about sub-projects in
> general, or if there are other projects we haven't mentioned that
> would make good sub-projects. It would be helpful to have some obvious
> "that's not a subproject" candidates as well.
> Chris
> --
> Chris Anderson

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message