incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: [policy] bring in full code history on incubated project?
Date Fri, 23 Dec 2005 22:26:13 GMT
--On December 23, 2005 1:33:34 PM -0800 "Roy T. Fielding" 
<> wrote:

> 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.

Is that a question of disclosure or responsibility?  Is your argument 
predicated on the fact that the ASF assumes no responsibility for the 
content of the imported history?  Are we shielded if it turns out that 
older releases did bad legal things that no longer apply to our code?  Is 
it permissible to commit code to our repositories that were under, say, GPL 
(for when a project, like SA, re-licenses)?

To put my Roy hat(tm) on, I'll venture to guess that your response will 
stem from the fact that the only cause for action is issuing a release. 
Therefore, since we didn't release that old code (of which we know 
nothing), it doesn't matter what we have in our code repositories.  Even if 
external committers didn't approve their changes to be a Contribution to 
the ASF when the project transfers, as long as we don't issue a release 
with that offending code, then we're fine.  Having items that are 
explicitly 'Not a Contribution' are okay in our source control is fine as 
long as it doesn't get released?  In fact, it'd be in our best interest to 
have the public history at our disposal so that we can trace the lineage as 
needed for purity purposes.

Am I close?  If so, then yes, I understand your reasoning.

However, I'm concerned with altering the perception that everything in our 
code repositories was done on our lists.  Instead, we'll now be conveying 
all of the oddball things that happened externally - be it at codehaus, 
SourceForge,, or wherever.

>> 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.

Subversion will look for an svn:author revision property.  We could change 
the svn:author field in the dumps to be an asf:external-contributor field 
or whatever and leave svn:author blank ("no author"), but I'm not quite 
sure how I feel about that.

It's a minor issue that could be resolved, I'm sure.  -- justin

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

View raw message