+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
