I think it's OK to just update the KEYS file.

Here's my evaluation result of 1.1.0 RC1:

1. sha1, md5, signature verified
2. build bigtop/slaves 1.1.0 images
3. use above 1.1.0 slave images to build 1.1.0 packages
4. run Docker Provisioner to deploy 1.1.0 packages
5. run Vagrant Provisioner to deploy 1.1.0 packages
6. run hadoop and pig smoke tests
7. run hadoop itest

Surely I didn't cover all the features, but the core feature I touched all
works well.
Hence here's my +1 to the RC1.


2016-02-07 15:23 GMT+08:00 Konstantin Boudnik <[email protected]>:

> Argh... the keys again. CB588E12 is one of my subs, but it is DSA key and
> we
> had a lot of troubles with the RPMs (because RPM only works with "secure"
> RSA
> keys). Eventually, for package signing I've used FA08B173, which is a part
> of
> the KEYS file.
>
> Technically, speaking there's no rule dictating to sign release artifacts
> and
> binary package with the same key. So, if having two keys is ok, then I will
> need to add CB588E12 to the KEYS as well. Or alternatively, I (or someone
> else) would need to do RC2 with correct signature.
>
> Cos
>
> On Sun, Feb 07, 2016 at 03:15PM, Evans Ye wrote:
> > Hi Olaf, did you get the key from keyserver?
> >
> > $  gpg --verify bigtop-1.1.0-project.tar.gz.asc
> bigtop-1.1.0-project.tar.gz
> > gpg: Signature made Sun Jan 31 12:09:46 2016 CST using DSA key ID
> CB588E12
> > gpg: Can't check signature: public key not found
> >
> > $ gpg --keyserver pgpkeys.mit.edu --recv-key CB588E12  # Took a while to
> > finish
> >
> > $ gpg --verify bigtop-1.1.0-project.tar.gz.asc
> bigtop-1.1.0-project.tar.gz
> > gpg: Signature made Sun Jan 31 12:09:46 2016 CST using DSA key ID
> CB588E12
> > gpg: Good signature from "Konstantin I Boudnik (Cos) <[email protected]>"
> > gpg:                 aka "Konstantin I Boudnik (Cos) <[email protected]>"
> > gpg: WARNING: This key is not certified with a trusted signature!
> > gpg:          There is no indication that the signature belongs to the
> > owner.
> > Primary key fingerprint: 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27
> E622
> >      Subkey fingerprint: 88C5 8332 D1A9 6A83 F9B3  2776 7A7C 8596 CB58
> 8E12
> >
> >
> > 2016-02-05 17:01 GMT+08:00 Olaf Flebbe <[email protected]>:
> >
> > > hi,
> > >
> > > the signature file is made with a key CB588E12 , not contained in KEYS.
> > > Or missed I something important?
> > >
> > > Olaf
> > >
> > > > Am 31.01.2016 um 05:35 schrieb Konstantin Boudnik <[email protected]>:
> > > >
> > > > This is the vote for release 1.1.0 of Apache Bigtop.
> > > >
> > > > It fixes the following issues:
> > > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311420&version=12329714
> > > >
> > > > The vote will be going for at least 72 hours and will be closed on
> > > Wednesday,
> > > > February 3rd, 2016 at noon PDT. Please download, test and vote with
> > > >
> > > > [ ] +1, accept rc1 as the official 1.1.0 release of Apache Bigtop
> > > > [ ] +0, I don't care either way,
> > > > [ ] -1, do not accept rc1 as the official 1.1.0 release of Apache
> > > Bigtop, because...
> > > >
> > > > Source and binary files:
> > > >  https://dist.apache.org/repos/dist/dev/bigtop/1.1.0-rc1
> > > >
> > > > Maven staging repo:
> > > >
> https://repository.apache.org/content/repositories/orgapachebigtop-1006
> > > >
> > > > The git tag to be voted upon is release-1.1.0
> > > >
> > > > Bigtop's KEYS file containing PGP keys we use to sign the release:
> > > >  https://dist.apache.org/repos/dist/release/bigtop/KEYS
> > > >
> > > > Thanks!
> > > >  Cos
> > >
>

Reply via email to