On 12/23/05, Roy T. Fielding <[EMAIL PROTECTED]> wrote: > On Dec 23, 2005, at 10:31 AM, Justin Erenkrantz wrote: > > > --On December 23, 2005 1:15:44 PM -0500 "Geir Magnusson Jr." > > <[EMAIL PROTECTED]> 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.
What if the donator wants to bring in the full history? ie) they're claiming that there is no danger in the information. > However, when a public open source code base comes to the ASF, we can > and should keep the full history. Problems with bringing in a full history: 1) Seems it would confuse the code grant? I'm sure a judge would have no clue, but I could easily see that someone donating code would assume that a code grant is for their code today, and not every public revision of their code. 2) Increases burden on Infrastructure. 3) Obstinate symmetry (ignoring technicalities) suggests we should bring in the mailing list archives and the issue tracker too. Roller's an interesting one on 3). We do want to bring in the issue tracker (unsure if there are any legal problems, who owns copyright on bug reports?) and when we bring the site over, it's a blog and I presume we'll be bringing the history of the blog over. Generally I think it should be done on a simplicity level. If a migration of XXX-resource is simple (or the incoming project works to make it simple), then there's no reason not to do it. If it's complex, then they have a choice of starting from scratch or making it simple. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
