Dims,
Can you be more specific? I don't want to put words in your mouth,
but it seems like you are suggesting we should avoid the incubator.
Is that what you are saying? If so, why? I am under the impression
that this is exactly what the incubator is designed to do.
I'm really interested in everyone's opinion, which is why I'm trying
to stay out of the discussion for a while. I have seen a few
comments like this in this discussion, but no one is being specific.
TIA
-dain
On Jul 12, 2005, at 2:10 PM, Davanum Srinivas wrote:
Aaron,
I have gotten quite a few projects processed thru incubator...so
please follow my advice :)
-- dims
On 7/12/05, Aaron Mulder <[EMAIL PROTECTED]> wrote:
On Tue, 12 Jul 2005, Davanum Srinivas wrote:
PMC's can maintain separate ACL's for each svn thingy. Get them to
become Apache committers, setup a separate svn area for them to
work.
Then VOTE them into regular geronimo project when you think they are
ready (each person on their merit).
Sorry, I must have misunderstood your previous line '+1 to
accept
new folks from these contrib as "regular" committers' -- I thought by
"regular" you meant "completely unrestricted".
I am OK with what you state above, though I still prefer the
incubator.
Aaroon
On 7/12/05, Aaron Mulder <[EMAIL PROTECTED]> wrote:
I'm sorry, I don't agree that donating code should
entitle a
company to nominate committers. Even separating the issue of
donating
code, I don't like adding committers when we don't know them,
aren't
familiar with their work, etc. I think it will be hard to
convince me
otherwise, but I am known to be conservative in this regard. :)
Given the above, I prefer the incubator because we can
all get to
know each other there, the people who know the code can have
immediate
commit on the code (as can interested Geronimo folks), we can start
working and evaluate the donation before deciding where it belongs
long-term, etc. It would be slightly more difficult to
integrate with
Geronimo for testing purposes, but we face similar issues with
OpenEJB and
TranQL already. On this, I am willing to be convinced that some
kind of
Geronimo sub-area is best, but I think the incubator is better as a
general rule.
As for why we need general rules, I don't fancy having this
extended dialogue every time there's a donation on the table. I
used to
think we wouldn't have that many donations, but after 2 in the
last month,
I'm not so sure.
And, of course, I support David J's statement of mentoring
principles and so on.
Aaron
On Tue, 12 Jul 2005, Davanum Srinivas wrote:
+1 to accept both the console and trifork code. Let Geir worry
about
paperwork. (Ask for a software grant from both companies such
that we
can place the code in our SVN.)
+1 to accept new folks from these contrib as "regular"
committers (we
can have a public vote once we get list of people from these 2
companies)
Why is this so difficult?
-- dims
On 7/12/05, Bruce Snyder <[EMAIL PROTECTED]> wrote:
After rereading this entire discussion, I'm still not sure
that we've
provided the requested guidance to the original reqeust that
started
this thread. What's more, given the debate that has taken
place, I'm
not sure that there's a consensus in any one direction. So
I've got a
couple of questions:
1) Is this the same management console that I downloaded from
Gluecode
as the Joe evaluation licensed product?
2) Will the management console come straight to Geronimo or go
through
the Incubator?
One additional suggestion on the table seemed to surround the
establishment of policies surrounding code donation. I'm not
clear on
why some people feel that policies need to be established. Why
are
people so hung up on establishing policies for so many things?
IMO,
rules for rules sake is just silly. I think we need to test
the waters
with some code donations before we go so far as to establish
policies
and precedents. Let's please crawl before we walk.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-
N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
