Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of flamefew@gmail.com designates
 64.233.162.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=gBBiGqyIlyGfzbrEfUgaNp4ROM6+S7qgSGF/hAXytgN2VEmo6tfFkDNPhHxGL3bpgUV6BOTqtQUjTEiwjMRqgFwTxSJCpfi6zW5jhKLNhpGWMPH2Ez9W6/jFsOaofHh+V2m1rUi3Ta5d7KuJ32QJo10ITcu0deSnFVOAuxuI3f8=
Message-ID: <31cc37360603151513u2f094cb0ia24ba9bc9b1a38f9@mail.gmail.com>
Date: Wed, 15 Mar 2006 15:13:46 -0800
From: "Henri Yandell" <flamefew@gmail.com>
To: dev@geronimo.apache.org, coar@apache.org
Subject: Re: ActiveMQ Graduation From Incubator
Cc: general@incubator.apache.org, activemq-dev@geronimo.apache.org,
	pmc@geronimo.apache.org
In-Reply-To: <4417F4EB.9080206@Golux.Com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <NBBBJGEAGJAKLIDBKJOPIEBHHBAC.noel@devtech.com>
	 <4417F4EB.9080206@Golux.Com>

On 3/15/06, Rodent of Unusual Size <Ken.Coar@golux.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Noel J. Bergman wrote:
> >
> > Personally, I believe that ActiveMQ ought to be a TLP.
>
> Just to be clear, though, that's just a personal opinion
> at this time, and in no way a 'dis is how t'ings is gonna
> be' statement.  Right? :-)
>
> > What makes a project with multiple codebases an umbrella is a gray
> > area.
>
> I've posted *my* first-pass definition of the term: a TLP that
> has no deliverable packages of its own, only from its subprojects.
> There's no 'Apache Jakarta' package, so it's an umbrella.
> There *is* an 'Apache HTTP Server' package, so that isn't.
> Subject to exceptions, clarifications, and further refinements,
> of course, but that's my working definition.

Ah, a subject dear to my heart. Here are some definitions I've been working=
 to:

* An umbrella. A collection of communities under a single community.

* A disjoint umbrella.  The situation in which the subcommunities of
an umbrella have low overlap - this is synonymous with the negative
meaning of "Jakartization" and the thing the board are trying to avoid
occuring in more than one place.

* The ASF. A disjoint umbrella.

* Jakarta Commons. A non-disjoint umbrella - works well, though it's
always a struggle to avoid entropy's slow pull towards disjoint.

History:

Jakarta: by means of being a disjoint umbrella - started to mimic the
foundation it was meant to be a part of. This is a redundancy problem
- we don't need N groups of people being foundations at the ASF - the
idea is for the foundation to be as small as it can be and still
support the communities for which it exists.

No more umbrellas: thus umbrellas became passe. The Incubator was
created as a managed umbrella to be a proto-foundation; the ASF
remains the primary umbrella. All the problems inherent in Jakarta and
other umbrellas remain; but they are now being dealt with by one group
- the board.

----

Speaking as an Incubator PMC member, I am currently -1 towards
Geronimo ActiveMQ and +1 towards Apache ActiveMQ. This is because I've
not yet heard much about how Geronimo plans to avoid disjointedness.

I do really like the point that Geronimo has a common product - but
I'm not sure it's enough. Plus how will it affect the use of the
subprojects (because subprojects they would be) as stand alones?

---

Lastly, speaking as someone who has used up the last couple of years
of his Apache time dealing with the problem of being the bridge
between a disjoint umbrella, and a board/foundation which is not
organized for dealing with disjoint umbrellas, I recommend not
creating a large umbrella.

Have TLPs and have each TLP's website be at geronimo.apache.org.
Investigate federations. Even investigate sharing mailing lists.
However do not give yourself the pain of trying to funnel it all
through a single chair. TLPs are not firewalled from each other
(though it's not very obvious that that's the case); so investigate
what it is you really want to achieve and don't focus on the single
TLP part of things.

TLPs are more about delegated oversight from the members/board, than commun=
ity.

Hen