On 30 June 2013 23:32, Benson Margulies <bimargul...@gmail.com> wrote: > On the one hand, I think that, in many Apache communities, comparing the > source release to the VCS is the exception and not the rule, and may never > have happened, even once. (I think that there is at least an even chance > that some crusty veteran of httpd will arrive in this thread and call me > out on this, insisting that Sebb's view is and has always been the only > right way, and some neuron in the back of my mind thinks it has seen some > reference to a tool for comparing source release packages to svn.) > > However, I don't see anything _bad_ about supplying an unambiguous, > immutable, reference to the VCS, and so it would be a good thing if Maven > helped Apache projects achieve this, rather than make it harder. > > So, if everyone here likes this idea, by all means let's do that. On the > other hand, if there is no consensus here, I wish that the Foundation had a > clearer venue for discussing global policies like this.
I hope I don't have to argue that it is ASF policy to only release source files whose provenance is known? My point is that the only practical way to establish provenance of the files in a source release is via the VCS/SCM. The reason the VCS coords need to be in the vote mail message is to allow a reviewer the opportunity to establish provenence. This applies for the current vote, and any potential review that might need to take place in the future. > > > > On Sun, Jun 30, 2013 at 4:56 PM, Fred Cooke <fred.co...@gmail.com> wrote: > >> > >> > OK, so what is the Git command to download a copy of the sources that >> > >> are part of the hash? >> > >> >> git checkout <hash> >> >> Then observe the tree. You can also export an archive, though I don't >> recall the exact command off the top of my hand. >> >> >> > Don't I need to know something about the Git repo it comes from? >> > >> >> Yes, the URL which would be pre-agreed. Providing it would be a nice >> convenience, but nothing more. >> >> >> > Or are Git hashes guaranteed to be universally unique? >> > >> >> Nothing is, however within the realms of SHA1 collisions, sure. The chances >> of finding a second repo for *any* other piece of software that contains >> the identical hash is pretty low. The chances of finding the same hash in a >> single Git repo is impractically low. I can't see how that is handled, but >> the obvious way would be to just respin the commit so the date meta data >> changed and the hash changed. In any case, if that's a flaw, it's a flaw of >> Git, and can't be avoided. In practice, it's not a flaw at all. >> >> > It's just sloppy not to do this; if a quality release process is >> required, >> > > so is the SVN rev number. If "good enough" is OK, then it can be >> omitted >> > > because you can, most of the time, just guess. Guessing = mistakes, >> > though. >> > >> > Sorry, I have to disagree there; the source reference cannot be >> > omitted under any circumstances because it's not possible to review >> > the source release without a reference to the files in SCM. There's no >> > way to determine provenance otherwise. >> > >> >> I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally >> unacceptable to me, however it seems like some people here think it's OK. I >> can see their point of view, however it's too easy to do it right to >> justify not doing it right. I agree with you, completely. >> >> Fred. >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
