incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: [policy] bring in full code history on incubated project?
Date Fri, 23 Dec 2005 21:33:34 GMT
On Dec 23, 2005, at 10:31 AM, Justin Erenkrantz wrote:

> --On December 23, 2005 1:15:44 PM -0500 "Geir Magnusson Jr."  
> <> wrote:
>> Sorry to change the subject...
>> Can someone make a definitive statement on whether or not code   
>> history
>> is brought into our repo from elsewhere when a podling brings   
>> code over?
> I say no.  We should only take in a snapshot.
> If people want to see the history that was done elsewhere, they are  
> free to maintain the old history outside.  What happened before the  
> ASF was involved is something we have no knowledge of and can't  
> speak to.  We can't be responsible for what happened before we were  
> involved.
> By only taking in a snapshot, we create a clean break from a social  
> and legal standpoint.  All work from that point is done under our  
> oversight mechanisms.  We can operate in good faith that the  
> snapshot we receive is in decent legal shape as we usually have a  
> software grant for the bulk of that work.  However, taking in  
> complete source history that we have no knowledge of the oversight  
> mechanisms that were in place is a bad thing in my opinion.

I disagree with Justin on these points.  We must have a clean break when
the code comes from a private source repository, since the history may
contain information that has never been revealed to the public.

However, when a public open source code base comes to the ASF, we can
and should keep the full history.  The history is already public, so
the ASF cannot be responsible for making it public.  Oversight is
irrelevant here because the ASF is not responsible for any of the
content within the history -- it is already public knowledge.  I does,
however, retain the author information, which is desired by us because
it allows credit to remain where it is due and allows everyone to
keep track of who needs to agree to the move.

> There is a lesser point that taking in the author information from  
> a separate project is awkward.  This presents conflicts with our  
> user account information and muddy things up if we ever have to do  
> an audit.  -- justin

Why don't we just run a script on the package before import, e.g.

    perl -pi -e 's/author/codehaus_author/g;' file

for the case of codehaus usernames.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message