Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Mon, 11 Jul 2005 22:13:39 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: dev@geronimo.apache.org
Subject: Donations & Policies
Message-ID: <Pine.LNX.4.58.0507112144060.17586@saturn.opentools.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	Okay, it seems I was was under the mistaken impression that 
everyone on the CORBA call wanted the TriFork code to come to a Geronimo 
"sandbox area", whereas in fact some people want it to go to the 
incubator.  I think that's totally acceptable, and I'm sorry I didn't walk 
away from the call with a clear picture of what people want.

	After giving the whole issue some more thought, I think I would
prefer the TriFork code go to the incubator.  I'm fine going either way
with the web console (incubator or "sandbox area" with own ACL).  I guess 
that means that if we need a single policy/guideline, I'd lean toward the 
incubator.

	Part of the thinking that went into this was I considered the
possible donation of an EJB container, web container, JMS broker, etc.  
All of those are pieces of every J2EE servers, and we've seen at least one
J2EE vendor willing to make donations.  I don't really think it would be
appropriate to bring one of those components I just listed directly into a
Geronimo sandbox.  We are already using high-quality open source projects
in each of those areas, and they're good at what they do, and I don't want
to insult them or ourselves be on the hook to support and maintain those
features.

	There are other smaller components we might accept into Geronimo
without conflicting, but I don't think we should base our
policy/guidelines on those.

Thanks,
	Aaron