On 25 February 2014 23:12, Lorin Beer <lorin.beer....@gmail.com> wrote: > Sebb, > > I've noticed in multiple posts from you a deep confusion over how our > project operates. > > To avoid generating unhelpful noise on our list and in the middle of > important discussions, I would respectfully suggest you follow some of the > links Joe Bowser has posted and educate yourself on how our project > operates and generates the releases.
Sorry, but the point is not really how the releases are generated. I'm sure you have a very good process. AIUI the point of this exercise is to audit the past releases to make sure the contents are all licensed. Noel Slater posted a very useful recipe here: http://wiki.apache.org/couchdb/Test_procedure#Checking_the_Candidate and this appeared to have been accepted by Marcel and others. However, the posting from Michal read to me as though he had misunderstood the rationale for the couchdb recipe; I was trying to explain how it is intended to work. > - Lorin > > > On Tue, Feb 25, 2014 at 2:37 PM, sebb <seb...@gmail.com> wrote: > >> On 25 February 2014 21:47, Michal Mocny <mmo...@chromium.org> wrote: >> > Some tips, since I found this a pain to figure out. To verify the sha >> file >> > matches: >> > >> >> gpg --print-md SHA512 *.zip | diff - *.sha && echo "Exact match" >> >> gpg --print-md MD5 *.zip | diff - *.md5 && echo "Exact match" >> > >> > Oddly the output of gpg is different than that of sha512sum and md5sum so >> > you cannot use those commands to --check the sums, ugh. (We should >> > consider changing the way we generate those files, no?). >> > >> > I'm still trying to figure out how to make sure the zip is signed >> > correctly, but am having issues setting up my KEYS. >> > >> > All-in-all I don't think this is that useful of a process to do, since to >> > be really confident you would have to create the full release zip from >> > scratch from source control yourself and compare *that* to the hosted zip >> > to make sure we releasing what you think we are (as is we are just >> > verifying the download isn't corrupt). But I wanted to go through the >> > process. >> >> I thought the idea was to compare the released zip with the source repo? >> i.e. unpack the release, and compare it with the contents of the tags >> in the repo. >> >> If all the files in the release zip have exact matches in a repo tag, >> then the release zip must be OK . >> >> If any zip files are missing from the repo, then this is a potential >> problem from the point of view of whether the file is suitably >> licensed. >> >> If repo files are missing from the zip, then perhaps there was an >> error creating the release. >> For a past release, that is not an issue - but of course it may be >> necessary to fix the process for the future. >> >> > >> > >> > On Tue, Feb 25, 2014 at 3:33 PM, Lorin Beer <lorin.beer....@gmail.com >> >wrote: >> > >> >> I've just submitted my +1 for a number of the past releases, and thought >> >> I'd document here what the steps I took were. >> >> >> >> Since these are past releases, some of which I helped tag and have >> already >> >> run, the checklist is slightly simplified: >> >> >> >> - download package >> >> - sanity check package for expected release artifacts >> >> - tags are correct >> >> - commit hash matches the source >> >> >> >> >> >> On Tue, Feb 25, 2014 at 11:35 AM, Steven Gill <stevengil...@gmail.com >> >> >wrote: >> >> >> >> > It has been brought to our attention that some of our previous >> releases >> >> > were not voted on in accordance with the ASF by-laws. After some >> >> > discussion, we've decided to call a retroactive vote on these >> releases. A >> >> > vote is being conducted by the PMC and the results will be posted here >> >> when >> >> > complete. >> >> > >> >> >>
