--On December 23, 2005 1:33:34 PM -0800 "Roy T. Fielding"
<[EMAIL PROTECTED]> 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, tigris.org, 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
