incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: [policy] bring in full code history on incubated project?
Date Tue, 27 Dec 2005 11:02:59 GMT
Hi gang,

I agree with Roy from a policy point of view. From a pragmatism point
of view I think the policy is "we SHOULD preserve history for existing
open source projects", but not a "MUST", because of the technical
difficulties (with SVN, no doubt solvable. With some other stuff (eg
bugzilla), less so).

I think for commercial projects, it'd be the ideal case that a commercial
party donates not just a code dump, but revision and development history
as well. Looking at OpenSolaris it is apparently sometimes possible to
retro-actively open source the "history" of a project too. I think in this
case its more a "MAY" than a "SHOULD" since there are a lot of "IF AND ONLY
IF"s.

cheers,

- Leo

On Fri, Dec 23, 2005 at 10:38:57PM -0800, Roy T. Fielding wrote:
> On Dec 23, 2005, at 2:26 PM, Justin Erenkrantz wrote:
> 
> >--On December 23, 2005 1:33:34 PM -0800 "Roy T. Fielding"  
> ><fielding@gbiv.com> 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?
> 
> Both.
> 
> >Is your argument predicated on the fact that the ASF assumes no  
> >responsibility for the content of the imported history?
> 
> No, that is a fact -- the ASF doesn't acquire responsibility for past
> acts simply by redistributing the code.  The entire repository is
> simply licensed to us for redistribution.
> 
> >Are we shielded if it turns out that older releases did bad legal  
> >things that no longer apply to our code?
> 
> Yes.  We are not responsible, and in any case we only have a license.
> 
> >Is it permissible to commit code to our repositories that were  
> >under, say, GPL (for when a project, like SA, re-licenses)?
> 
> Yes. Relicensing means the copyright owners offer a different set
> of terms for the same code -- they do not have to change the files
> for that to take effect.
> 
> >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.
> 
> Close enough.  Also, if one of those people goes psychotic and tries
> to sue the ASF for copyright infringement, we merely point out that
> the publication in subversion is no different from the open source
> license that they originally published under.
> 
> >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.
> 
> That's life.  How much code under httpd "was done on our lists"?
> Probably more than any other project, yet I can still point to
> several thousand lines that were not.
> 
> >>>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.
> 
> I think you are missing the point.  Apache traditionally has said that
> authors are given credit for their work within the changelog and
> version history.  Removing the history from a previous open source
> project scrubs the credits for the original authors.  At least one
> potential contributor finds that offensive.
> 
> What I suggested was prefixing each author in the old dump with
> something to indicate that author name came from some other subversion
> or cvs namespace, thereby avoiding the conflict with our own names
> while still retaining credit for the original developers.
> 
> ....Roy
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message