If creating native deb/rpm package signatures and repo metadata
signatures is the only issue that stops us from releasing more often and
sharing the burden in doing so, then I'd be happy to discuss dropping
this altogether. We can always distribute binary packages along with
checksums and a detached gpg signature by any KEYS person, just as we do
with the tarballs.
Having an Apache hosted Cassandra yum/deb repo may be convenient, but I
wonder how many users will still download the packages and host them in
their own internal repo. Even if it's just to have the option to pin the
package to a specific version, which we currently don't offer, as only
the latest package is included in the repo metadata. It might also
encourage distros to keep downstream repos updated as well, since that
would be the ideal way of creating and distributing package, i.e. having
a Debian/Fedora/Ubuntu maintainer taking care of that and only have
users come back to us for the vanilla rpm in case their downstream
version is outdated.
On 08.01.19 02:48, Michael Shuler wrote:
Yeah, I asked if someone made a request thinking I totally missed it!
Since the last couple tick-tock releases, which were time based, every
release has been initiated by someone commenting in IRC or dev@ that
"there are a lot of things in CHANGES.txt" or "important fix foo has
been committed, let's release". It looks like the interval on releases
has been about 4-6 months, so we're due :)
More packaging / GPG key tickets, if someone wants to take them on:
https://issues.apache.org/jira/browse/CASSANDRA-14966
https://issues.apache.org/jira/browse/CASSANDRA-14967
https://issues.apache.org/jira/browse/CASSANDRA-14968
I see other Debian and RPM type repositories configured in the Apache
bintray project, so perhaps signing of the package repositories can be
done using their signing feature(?).
I just really wish to cause users installation/upgrade difficulty as
little as possible. If we're going to change up to something that allows
more people to do maven and tarball releases, great, I don't care, since
there's no tar-install-client that cares. I absolutely don't want
deb/rpm package repository users to constantly need to update GPG keys
every release, that's not nice to our users. If there is a way to get
the repos set up correctly in bintray, and it's OK with INFRA to use the
bintray key signing feature, great. We should set up a new package
signing key and configure bintray to sign the metadata. One change for a
long-term solution.
Michael
On 1/7/19 4:34 PM, Jeff Jirsa wrote:
I dont think it's awkward, I think a lot of us know there are serious bugs
and we need a release, but we keep finding other bugs and it's super
tempting to say "one more fix"
We should probably just cut next 3.0.x and 3.11.x though, because there are
some nasty bugs hiding in there that the testing for 4.0 has uncovered.
On Mon, Jan 7, 2019 at 2:14 PM Jonathan Haddad <j...@jonhaddad.com> wrote:
I don't understand how adding keys changes release frequency. Did
someone request a release to be made or are we on some assumed date
interval?
I don't know if it would (especially by itself), I just know that if more
people are able to do releases that's more opportunity to do so.
I think getting more folks involved in the release process is a good idea
for other reasons. People take vacations, there's job conflicts, there's
life stuff (kids usually take priority), etc.
The last release of 3.11 was almost half a year ago, and there's 30+ bug
fixes in the 3.11 branch.
Did someone request a release to be made or are we on some assumed date
interval?
I can't recall (and a search didn't find) anyone asking for a 3.11.4
release, but I think part of the point is that requesting a release from a
static release manager is a sign of a flaw in the release process.
On a human, note, it feels a little awkward asking for a release. I might
be alone on this though.
Jon
On Mon, Jan 7, 2019 at 1:16 PM Michael Shuler <mich...@pbandjelly.org>
wrote:
Mick and I have discussed this previously, but I don't recall if it was
email or irc. Apologies if I was unable to describe the problem to a
point of general understanding.
To reiterate the problem, changing gpg signature keys screws our debian
and redhat package repositories for all users. Tarballs are not
installed with a client that checks signatures in a known trust
database. When gpg key signer changes, users need to modify their trust
on every node, importing new key(s), in order for packages to
install/upgrade with apt or yum.
I don't understand how adding keys changes release frequency. Did
someone request a release to be made or are we on some assumed date
interval?
Michael
On 1/7/19 2:30 PM, Jonathan Haddad wrote:
That's a good point. Looking at the ASF docs I had assumed the release
manager was per-project, but on closer inspection it appears to be
per-release. You're right, it does say that it can be any committer.
http://www.apache.org/dev/release-publishing.html#release_manager
We definitely need more frequent releases, if this is the first step
towards that goal, I think it's worth it.
Glad you brought this up!
Jon
On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever <m...@apache.org>
wrote:
I don't see any reason to have any keys in there, except from release
managers who are signing releases.
Shouldn't any PMC (or committer) should be able to be a release
manager?
The release process should be reliable and reproducible enough to be
safe
for rotating release managers every release. I would have thought
security
concerns were better addressed by a more tested process? And AFAIK no
other
asf projects are as restrictive on who can be the release manager role
(but
i've only checked a few projects).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
--
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
