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 >
