I have been waffling a bit back and forth on this issue...but I think I
have come to terms on my thinking on this subject.
I am not sure a "concrete" policy is necessary. Every piece of code
that comes through as a donation, either from a commercial vendor or
from another open source project or community will have different
manners in which they come through the door. Some may approch the PMC
first. Some may just announce the desire on the the lists. Each on
will be different.
How we handle each of these projects will likely not be the same
niether. Some may flourish as a sub project to stand on thier own, some
are good for just being Geronimo specific. A good example is the
console vs Trifork. Clearly one can live on its own where the other cannot.
Perhaps "guidelines" or a howto, that offers options on how to get your
code into the project as a opposed to a "policy'. Ultimately, IMHO,
each will be individually handled based on the merits and direction of
the code base coming in, as well as any additional baggage that comes
along with it.
David Blevins wrote:
("superb support and mentoring for our new members and left the
questions of what to do if we fail to such time as it might be
needed.")
+1 Building relationships, mentoring, thousand points of light.
Respectfully,
David
On Tue, Jul 12, 2005 at 10:32:48AM -0700, David Jencks wrote:
In order to avoid mile-long emails I'm starting over.
I think our overall goal is to strengthen the geronimo community by
bringing in new developers and code that we as well as they want to
work on.
This process is likely to be more work for us than the new developers,
since they already know their code very well, whereas we need to learn
their code and more importantly mentor them into being part of the
geronimo community. Therefore, we need to put together a process that
involves the least work for us, and we need to commit the time needed
to be good mentors. To me, this means that the new people need to be
given commit access to at least their donated code, since we simply
won't have time to review all the patches that are likely to result
otherwise, and the svn structure needs to be set up for minimal
nuisance/simplest builds. I think the last would be best with the new
code going somewhere in the geronimo/trunk tree: although svn tricks
are certainly possible to pull it in from elsewhere in apache svn, this
would add some complexity for no gain I can see.
I also think it is important to publish a process for donations, so we
don't spend weeks discussing this every time someone offers something,
and so potential donors know what to expect and dont get the idea that
we are playing favorites. If we run into problems, we can certainly
update the process.
I'd like to reemphasize that bringing in new committers with their code
is going to be a lot of work for the existing community. If we fail to
integrate a donation a very large part of the responsibility rests with
us for not having good enough community skills to work with the
newcomers. It seems to me that discussions about limited commit
access/ acls/ etc are fundamentally discussions about what happens if
we fail. I wonder what would happen if we instead discussed how we
will provide superb support and mentoring for our new members and left
the questions of what to do if we fail to such time as it might be
needed.
thanks
david jencks
