Voting on past releases

[Steven Gill <st...@gmail.com>]

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.

Re: Voting on past releases

[Joe Bowser <bo...@gmail.com>]

I'm just going to leave this here:

http://git-scm.com/book/en/Getting-Started-Git-Basics

http://wiki.apache.org/cordova/CuttingReleases
On 25 Feb 2014 14:38, "sebb" <se...@gmail.com> wrote:

> On 25 February 2014 21:47, Michal Mocny <mm...@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.dev@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 <stevengill97@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.
> >> >
> >>
>

Re: Voting on past releases

[Michal Mocny <mm...@chromium.org>]

Sorry to add confusion, I chose my phrasing poorly. I do understand the
rationale.

When I said "All-in-all I don't think this is that useful of a process to
do" I meant specifically for the single step of checking the bundled zip to
match the bundled hash, not the whole process of verifying the contents of
the release against the sources, which everyone is doing well.

Please lets refrain from taking this constructive process off track now.


On Tue, Feb 25, 2014 at 6:44 PM, sebb <se...@gmail.com> wrote:

> On 25 February 2014 23:12, Lorin Beer <lo...@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 <se...@gmail.com> wrote:
> >
> >> On 25 February 2014 21:47, Michal Mocny <mm...@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.dev@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 <
> stevengill97@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.
> >> >> >
> >> >>
> >>
>

Re: Voting on past releases

[sebb <se...@gmail.com>]

On 25 February 2014 23:12, Lorin Beer <lo...@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 <se...@gmail.com> wrote:
>
>> On 25 February 2014 21:47, Michal Mocny <mm...@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.dev@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 <stevengill97@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.
>> >> >
>> >>
>>

Re: Voting on past releases

[Lorin Beer <lo...@gmail.com>]

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.

- Lorin


On Tue, Feb 25, 2014 at 2:37 PM, sebb <se...@gmail.com> wrote:

> On 25 February 2014 21:47, Michal Mocny <mm...@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.dev@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 <stevengill97@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.
> >> >
> >>
>

Re: Voting on past releases

[sebb <se...@gmail.com>]

On 25 February 2014 21:47, Michal Mocny <mm...@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 <lo...@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 <stevengill97@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.
>> >
>>

Re: Voting on past releases

[Joe Bowser <bo...@gmail.com>]

I'm checking Cordova JS.  The process gets extremely predictable once
we get into everyone using Coho.

On Tue, Feb 25, 2014 at 1:47 PM, Michal Mocny <mm...@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.
>
>
>
> On Tue, Feb 25, 2014 at 3:33 PM, Lorin Beer <lo...@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 <stevengill97@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.
>> >
>>

Re: Voting on past releases

[Michal Mocny <mm...@chromium.org>]

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.



On Tue, Feb 25, 2014 at 3:33 PM, Lorin Beer <lo...@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 <stevengill97@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.
> >
>

Re: Voting on past releases

[Lorin Beer <lo...@gmail.com>]

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 <st...@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.
>