Julian Hyde <mailto:jh...@apache.org>
October 17, 2014 at 6:49
This vote has been open 8 days, and has two +1 votes. There has been a
lot of discussion, but I don't think any issues have been discovered
which would stop the release. We seem have reached impasse.
I plan to close this vote in 24 hours. If we get one more +1, the vote
will pass. If we don't, I will cancel the vote.
Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
sebb <mailto:seb...@gmail.com>
October 14, 2014 at 4:57
On 13 October 2014 17:11, Dennis E. Hamilton<dennis.hamil...@acm.org> wrote:
I suggest that the release manager and anyone else in the KEYS file should
have added key fingerprints to their Apache profiles at<https://id.apache.org/>.
This will have their PGP keys refreshed regularly under their Apache ID at
<https://people.apache.org/keys/committer/>.
With regard to an identifiable association of the key, presence in this
manner connects the PGP key to The Apache ID by demonstration of control
over the committer's Apache profile.
Similar traceability applies if the user adds their key to the KEYS
file in SVN at
https://dist.apache.org/repos/dist/release/<TLP>/[path/]KEYS
[This file is required for providing the keys to downloaders]
But no harm in adding the key to LDAP as well.
One can go farther by adding the user...@apache.org to an User-ID on the key.
Verifying that one has control over that e-mail address (and all User-IDs)
Is done by registering the public key at the PGP Global Directory service at
<https://keyserver2.pgp.com/vkd/GetWelcomeScreen.event> and completing the
ceremony specified there. After the ceremony is completed, you can retrieve
your counter-signed PGP key from that service and synchronize it to a public
PGP key server. The ASF will pick it up on a future refresh.
Use of the key from the Apache ID list has certain valuable properties. It is
not fixed, as in the key files in the project and in distributions. That means
any additional (web-of-trust) certifications of the keys association with a
committer are updated automatically. That includes any revocations.
The keys from the ASF ID list also have disadvantages.
Keys are used to sign artifacts for projects, and need to remain
available whilst the artifact remains available.
That includes archived artifacts.
-- Dennis E. Hamilton
dennis.hamil...@acm.org +1-206-779-9430
https://keybase.io/orcmid PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail
-----Original Message-----
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Sunday, October 12, 2014 22:29
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)
Hi,
First, the signing key is present in SVN, but has not been uploaded to the
standard key-servers, nor has it been signed by anyone.
I found it here:
https://pgp.mit.edu/pks/lookup?search=Julian+Hyde&op=index
Even if the key is part of a web trust it may not be part of everyone's web of
trust. I'd see that as a hard requirement to meet.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Dennis E. Hamilton <mailto:dennis.hamil...@acm.org>
October 13, 2014 at 9:11
I suggest that the release manager and anyone else in the KEYS file
should
have added key fingerprints to their Apache profiles at
<https://id.apache.org/>.
This will have their PGP keys refreshed regularly under their Apache
ID at
<https://people.apache.org/keys/committer/>.
With regard to an identifiable association of the key, presence in this
manner connects the PGP key to The Apache ID by demonstration of control
over the committer's Apache profile.
One can go farther by adding the user...@apache.org to an User-ID on
the key.
Verifying that one has control over that e-mail address (and all User-IDs)
Is done by registering the public key at the PGP Global Directory
service at
<https://keyserver2.pgp.com/vkd/GetWelcomeScreen.event> and completing the
ceremony specified there. After the ceremony is completed, you can
retrieve
your counter-signed PGP key from that service and synchronize it to a
public
PGP key server. The ASF will pick it up on a future refresh.
Use of the key from the Apache ID list has certain valuable
properties. It is
not fixed, as in the key files in the project and in distributions.
That means
any additional (web-of-trust) certifications of the keys association
with a
committer are updated automatically. That includes any revocations.
-- Dennis E. Hamilton
dennis.hamil...@acm.org +1-206-779-9430
https://keybase.io/orcmid PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail
-----Original Message-----
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Sunday, October 12, 2014 22:29
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)
Hi,
I found it here:
https://pgp.mit.edu/pks/lookup?search=Julian+Hyde&op=index
Even if the key is part of a web trust it may not be part of
everyone's web of trust. I'd see that as a hard requirement to meet.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Justin Mclean <mailto:jus...@classsoftware.com>
October 12, 2014 at 22:28
Hi,
I found it here:
https://pgp.mit.edu/pks/lookup?search=Julian+Hyde&op=index
Even if the key is part of a web trust it may not be part of
everyone's web of trust. I'd see that as a hard requirement to meet.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Ted Dunning <mailto:ted.dunn...@gmail.com>
October 12, 2014 at 19:39
I just looked a bit a this release and I have a few questions. I am
uncertain about how these issues should lead to a vote, but would tend
toward saying that this is OK for a first incubator release on condition
that these issues should be rectified in subsequent releases.
I would appreciate guidance from Marvin or other folk experienced in these
matters about this.
First, the signing key is present in SVN, but has not been uploaded to the
standard key-servers, nor has it been signed by anyone. I don't think that
this has been made a failing criterion for releases yet, but it does
appear
that Apache is moving towards requiring a web of trust around public keys
used for signing. It would be good to rectify this by uploading a signed
key.
Then, there is a DEPENDENCIES file which contains licensing
information for
dependencies that are not included in the distribution. That DEPENDENCIES
file contains information on many of the dependencies, but not all. I
think that this file be deleted or made whole.
Also, I ran [mvn rat:check] and noted that it failed. The reason for the
failure is relatively benign in that the objections are for files such as
git.properties, some mark-down files and a file containing the textual
name
of a class which do not have a recognizable license. Adding the following
to the top-level pom will suppress these messages and allow rat to
complete
successfully:
<plugin>
<groupId>org.apache.rat</groupId>
<artifactId>apache-rat-plugin</artifactId>
<executions>
<execution>
<id>rat-checks</id>
<phase>validate</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<configuration>
<excludeSubProjects>false</excludeSubProjects>
<excludes>
<exclude>**/*.md</exclude>
<exclude>**/*.json</exclude>
<exclude>**/*.parquet</exclude>
<exclude>**/META-INF/services/java.sql.Driver</exclude>
<exclude>**/git.properties</exclude>
<exclude>**/target/rat.txt</exclude>
</excludes>
</configuration>
</plugin>
On a more positive note, I reviewed the NOTICE and LICENSE and they are in
order for a pure apache source release that embeds no externally licensed
code. These would have to be different in a binary release, of course, if
convenience jars are included, but there is no binary release at this time
so that is not yet an issue.
