On 30 June 2013 19:48, Fred Cooke <fred.co...@gmail.com> wrote: > For Git the only thing that is needed is the unique 40 character hash such > as this: > > FreeAir:youtube-dl fred$ git rev-parse HEAD > 48bfb5f2387ab47e1973d9db0782a9af66ffc4e6
OK, so what is the Git command to download a copy of the sources that are part of the hash? Don't I need to know something about the Git repo it comes from? Or are Git hashes guaranteed to be universally unique? > 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. > Fred. > > On Sun, Jun 30, 2013 at 8:20 PM, sebb <seb...@gmail.com> wrote: > >> The mission of the ASF is to release software as source, and to ensure >> that the released source is available under the Apache Licence. >> >> Before a release can be approved it must be voted on by the PMC. >> The review process needs to establish that the proposed source release >> meets those aims. >> >> It's all but impossible for reviewers to examine every single file in >> a source archive to determine if it meets the criteria. >> >> However, PMCs are also required to check what is added to the SCM >> (SVN/Git) to make sure it meets the required license criteria. >> This is done on an ongoing basis as part of reviewing check-ins and >> accepting new contributions. >> >> So provided that all the files in the source release are also present >> in SCM, the PMC can be reasonably sure that the source release meets >> the ASF criteria. >> >> Effectively the SCM can be viewed as a database of pre-approved files. >> >> Without having the SCM as a database of validated files, there are far >> too many files in the average source archive to check individually. >> And how would one check their provenance? The obvious way is to >> compare them with the entries in SCM. >> >> Therefore, I contend that a release vote does not make sense without >> a unique reference to the source files that were used to create the >> release. >> >> In the case of SVN, since tags are not guaranteed immutable, the vote >> e-mail also >> needs the revision. The revision alone is not sufficient, because the >> ASF SVN is shared. >> >> Now whether every reviewer actually checks the source archive against SCM >> is another matter. >> >> But if the required SCM information is not present, it would be >> difficult to argue that the RM had provided sufficient information for >> a proper review to take place. In which case the vote cannot be >> considered valid. >> >> The vote thread needs to provide all the information that is needed to >> properly review the release candidate, otherwise IMO it is not a valid >> vote. >> This is needed both at the time of the vote, and for historic reasons >> so the context of the vote is properly recorded. >> >> Please do not obscure this thread with discussions of the release >> plugin or tags or merits of Git/SVN. >> Such technical aspects belong in separate threads. >> They obviously important to the process, but not the vote, which is >> about the result. >> >> Reminder: all this thread is just about is adding the following lines >> to vote e-mails: >> >> SVN Tag: >> >> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ >> (r1496317) >> >> or whatever the equivalent is for Git (or any other SCM that may be in >> use at the time). >> >> --------------------------------------------------------------------- >> 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
