harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: [legal] Bulk contribution barrier to entry
Date Tue, 11 Oct 2005 09:10:11 GMT
On Mon, Oct 10, 2005 at 06:08:20PM -0400, Geir Magnusson Jr. wrote:
> See http://incubator.apache.org/harmony/ 
> bulk_contribution_checklist.html  Part III
> 
> This is a very high standard,

I thought it was a checklist.

> However, I suspect it will be too high of a standard.  For example,  
> suppose the Kaffe project wanted to offer a copyright license to  
> their codebase to Harmony?  I bet it can't be done - we'd have to  
> chase down every contributor to the codebase and get the signed  
> agreement.  Suppose Sun wanted to donate J2SE?  :)  I'm betting they  
> couldn't provide the necessary documentation either...
> 
> So what do we do?

Just-in-time revise the process when the problem arrives?

They check the appropriate checkboxes. For example, Sun donating J2SE
would check the box "no" and then provide details along 
the lines of

"authors are sun employees."

"attached is a list of sun's employees over the last 10 years who we
believe have worked on this contribution. Also attached is a list of
companies which we have agreement such and so forth with."

Now, if and when Sun states that they want to contribute something
for which they can't fill in the template, we create a new one (its
versioned isn't it) which they can fill in.
 
> We need to balance a few things:
> 
> 1) Make this flexible enough that the project can choose to accept  
> software for which ACQs aren't obtainable from all authors.
> 2) Make this strong enough that we don't put the project at  
> unreasonable risk, and that the consumers of the software have  
> confidence that the codebase is clean.
> 
> Suggestions?  One possibility is that for those that can't satisfy  
> the status quo framework, we have a set of questions that allow us to  
> understand the source of the code and the manner in which it was  
> developed.  We'd like this to be somewhat objective yet still give  
> the project room to reject if it doesn't "feel right", we want the  
> process used and information obtained to be available to the public  
> so that any interested consumer of our software can understand where  
> it came from.
> 
> Ideas?

We'll have to change other bits of process too. If sun contributes J2SE
I doubt we'll want to make all J2SE developers at sun, past and present,
committers to the project. That's gotta be lots of people!

I know very little about any of this, but I'll suggest that designing
ahead of need is not a good idea. If and when we run into problems with
this process, we will know exactly what the problem actually is and
what steps would fix that problem.

Software developers will recognize this is as the "extreme programming"
approach :-)

LSD


Mime
View raw message