couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Hartung <wi...@mirthcorp.com>
Subject Re: Apache sub-projects
Date Fri, 14 Aug 2009 22:11:45 GMT
On Fri, Aug 14, 2009 at 1:59 PM, Shaun Lindsay<shaun@meebo.com> wrote:
> 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.

That's a key consideration, I think.

Taking lounge as an example, if Couch intends to offer "lounge
capability" as a first class service, and, in the end, obsolete
lounge, then the decision needs to be made whether to "incorporate and
absorb" lounge, or, effectively, "compete against" lounge.

Making it a 'sub project', leads more towards the former "incorporate"
option. If it intends to compete, then, clearly, lounge has no formal
place within the project.

Mind, even if lounge in its current incarnation goes against the way
"most folks" would want to eventually see lounge-like capability
implemented in couch (i.e. native erlang rather than a bolted on,
external service, or whatever), incorporating the existing project
with the intent towards incorporation helps funnel the energy and more
formally direct the effort.

Now, on a related note, I think there is a down side to sub projects
and incorporation.

Using lounge as an example, I would expect, as a consumer, that when
Couch reaches the next version, whatever or whenever that may be, the
sub projects should follow along. If I download the latest CouchDB, I
should be able to download the matching, tested, approved version of
CouchDB Lounge at the same time.

Specifically, I think once under the umbrella, the project as a whole
is responsible for maintaining and testing these sub projects.

If lounge was maintained outside of the Couch project, for example,
then the fact that Couch .10 or .11 "broke lounge" isn't a CouchDB
Project issue, it's a couch-lounge projects maintainers issue. In a
CouchDB projects issue in terms of "customer service", "friendliness
to outside developers", etc. But, in the end, the fact that an
external project "isn't keeping up", isn't a project issue as a whole.

Whereas if lounge were a sub project of Couch, I can see that the fact
that lounge didn't work would be a release stopping issue that must be
resolved (minimally considered) before a new Couch release comes out.

Now, I'm not saying any of this is or isn't happening with the
couch-lounge project specifically, I merely use it as a potential
example.

If sub projects don't fall under this kind of formal attention, then I
don't see what value they really have over simply having a list of
links to "good projects that work with couch" on the wiki or web site.

Regards,

Will Hartung

Mime
View raw message