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
