Mick's absolutely right. Even if we had been doing more frequent releases, it's a big risk for us to only have one person able to it in the first place.
I also agree with Benedict. I don't think we need to be crazy strict about windows. As long as we tell folks they may need to import keys, I think we're much better off than we are now. On Thu, Oct 17, 2019 at 5:08 AM Benedict Elliott Smith <bened...@apache.org> wrote: > +1 > > We need to do something about this, and I don't mind what. It would be > better if we cut fix releases immediately after a critical fix lands, much > as we used to. We've got fairly lazy about producing releases, perhaps > because many of the full-time contributors now work for organisations that > don't really need them. > > We should definitely add any willing volunteers to the KEYS file now. I > don't personally think we need any kind of a strict policy about modifying > it in future, except that if our release cadence drops and we have willing > volunteers we should do it again. > > > On 17/10/2019, 07:50, "Mick Semb Wever" <m...@apache.org> wrote: > > > > We're still in the position where only four people in the project: > > Michael, Sylvain, Jake, and Eric; can cut, stage, and propose a > > release. > > > Our current patch release frequency is lacking. It's been 8 months > since 3.11.4. > This is having an impact on users and their faith in the technology. > > There is currently only one person in the community that is actively > making releases. This really doesn't inspire confidence. We really should > be cutting a patch release every 2 to 6 weeks, if critical fixes apply, > imho. And I for one would certainly like to be helping out with this > situation. > > If we choose to address this issue, there are two facets to it that > come to mind: > 1) This misnomer that committers can't cut and publish releases. > 2) That we can't make changes to the KEYS file (or that it's too > painful to do so). > > Re (1). I'm not sure where this misunderstanding came from in our > community. But the ASF policy does not prevent committers from being the > release manager. By default the only thing in the process a committer can't > do is publish the successfully voted upon release from stage to public. > This is a one-line svn command and the last and very small action in the > release process at large. A committer can coordinate, cut, stage, announce, > and initiate the vote on a release, which is the bulk of the work. And the > committer can also do the final publish command if the PMC has voted that > this is ok in this community. This is all in > http://www.apache.org/legal/release-policy.html > > > > Is it time to add more people to our KEYS file? > > This will have the consequence that debian users will have to re-add > it. > > > Re (2), the problem is that changes to the KEYS file mean that debian > users have to re-import it before pulling new packages. But is that really > worse than an 8 month or more for an earlier patch version like ".5" ? > > > > But maybe we can accept a window, from now until the first 4.0 rc, > > where all committers are free to open a PR to add themselves to the > > KEYS file? > > > I can think of a number of ways forward on this. > a) remove the constraint that we can't update the KEYS file, asking > debian users to be prepared to have to re-import it. > b) open a one-off window where we get as many PMC and Committers as > possible to add their gpg key to the KEYS file. > c) open a regular window each year, eg last quarter, where we > collect new keys to add from new PMC and Committers, and merge them all in, > in one go, at the end of that window. > > It would be great to be in a better place than the current situation > where we have only four keys in the file :-( > > regards, > Mick > > --------------------------------------------------------------------- > 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 > >
