> Contributors - in general - would need to take more care to ensure > that code was only pulled in from sources covered by a license > agreement
Robert, I'm not sure how this differs from a patch someone provides? Can you please elaborate what you think that the difference is here? Imho both (patch and git commits) only are diffs to a very certain codebase. Even more certain for git commits, because they start from another commit which is already uniquely identified via it's SHA1 (pulled from the canonical central repo). Imho this is an organisatorial problem not a technical one. Gerrit may also check for a 'ASL2 license granted' flag like it's solved in issues.apache.org for patches. LieGrue, strub --- Robert Burrell Donkin <robertburrelldon...@gmail.com> schrieb am Fr, 24.4.2009: > Von: Robert Burrell Donkin <robertburrelldon...@gmail.com> > Betreff: Re: Using GIT as the canonical repository for Maven 3.x > An: "Maven Developers List" <dev@maven.apache.org> > Datum: Freitag, 24. April 2009, 20:17 > On 4/24/09, Jason van Zyl <jvan...@sonatype.com> > wrote: > > > > On 24-Apr-09, at 7:55 AM, Robert Burrell Donkin > wrote: > > > >> On Fri, Apr 24, 2009 at 3:46 PM, Jason van Zyl > >> <jvan...@sonatype.com> > wrote: > >>> On 24-Apr-09, at 7:36 AM, Robert Burrell > Donkin wrote: > >>> > >>>>> > >>>>> Is sounds like the process used by our > release plugin doesn't > >>>>> really > >>>>> match > >>>>> the way git works, so maybe we can > change the way the release > >>>>> plugin > >>>>> works > >>>>> instead of trying to fit git into our > model. Do we really need > >>>>> to do a > >>>>> clean checkout from the tag? Git > must have a way to just check > >>>>> that the > >>>>> local working copy is exactly the same > as the tag on the server, > >>>>> right? > >>>>> As > >>>>> long as we have a good way to verify > that what we have locally > >>>>> matches > >>>>> what's on the server, I don't think > it's absolutely necessary to > >>>>> do a > >>>>> clean > >>>>> checkout. > >>>> > >>>> this goes to the heart of the major > problem with code provenance > >>>> which > >>>> needs to address when considering GIT for > a permissively licensed > >>>> project. how can the provenance of a > release be understood unless a > >>>> canonical version history is available for > that release? > >>>> > >>> > >>> Already solved more then adequately with > Gerrit. The Google Android > >>> team > >>> uses GIT with a canonical repository and all > contributions are > >>> managed > >>> through Gerrit. JGIT and Gerrit are pure Java > and so adding to the > >>> already > >>> sophisticated peer review system would be > easy. Right now review and > >>> approval is a few clicks. I'm sure Shawn > Pearce would help us > >>> create an > >>> awesome mechanism for governance but I imagine > most of this is there > >>> already. The public GIT repository for Android > can accept patches > >>> from > >>> external contributors and I imagine Google has > the legal work > >>> sorted out. > >> > >> ok > >> > >> so AIUI a central repository would so be used with > patches accepted > >> from the community by committers. this sort of > push mechanism (with > >> contributors submitting patches) would work fine > with the apache > >> licensing arrangement provided that the canonical > repository was > >> hosted by apache. > >> > >> is that about right? > >> > > > > Correct. The model that Android uses I would say is > optimal for an > > open source project. People can take real copies and > derive all the > > benefit from that, but they push to a gatekeeper where > submissions are > > vetted. Gerrit represents some pretty cool innovation > insofar as > > collaboration goes. > > So far so good > > Gatekeepers pushing from local repositries would need to > ensure that > everything pushed to center was either their own original > work or > credited/audited as per the iCLA. > > Contributors - in general - would need to take more care to > ensure > that code was only pulled in from sources covered by a > license > agreement (the ASL2.0 grant only covers active > contributions). > (Reciprocal licenses don't have this problem.) May need > some > lightweight process here - be interesting to see how Google > approaches > this. > > Robert > > > > > >> - robert > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > Thanks, > > > > Jason > > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > http://twitter.com/SonatypeNexus > > http://twitter.com/SonatypeM2E > > > ---------------------------------------------------------- > > > > Selfish deeds are the shortest path to self > destruction. > > > > -- The Seven Samuari, Akira Kurosawa > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
