geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: Donations & Policies
Date Tue, 12 Jul 2005 21:38:45 GMT
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 
>>david jencks

View raw message