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? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
