Noted:
https://issues.apache.org/jira/browse/CASSANDRA-14963
Fundamental current docker build flaws:
https://issues.apache.org/jira/browse/CASSANDRA-14962
Distribution changes suggested for deb/rpm:
https://issues.apache.org/jira/browse/CASSANDRA-14966
https://issues.apache.org/jira/browse/CASSANDRA-14967
..which are dependencies of repository sig changes to solve the whole
KEYS file pain for package users, for ever and ever:
https://issues.apache.org/jira/browse/CASSANDRA-14968
There are other ASF projects using bintray metatdata signing (the repo
metadata is *not* a release artifact). Artifact sigs uploaded to /dist/
and subsequent verification from KEYS seem orthogonal to repo metadata
signatures to me. I don't see why we cannot do the same as quite a few
other projects and use automated bintray repo signing, migrating to
appropriate bintray repository types.
I believe some basic distribution changes would greatly help the entire
question here, including making release builds easier for other people
to perform, shortening the cycle times as desired. If there is some
interest in building releases, I would like some help solving the
problems that exist and have been in JIRA for quite some time.
--
Kind regards,
Michael
On 10/17/19 8:41 AM, Joshua McKenzie wrote:
Might make sense to split the difference and have a loose reactive policy
of "consider / discuss a potential release when any of the following are
hit":
1. something critical is merged (data loss fix, cluster down fix, etc)
2. there are <M> changes to the branch
3. it's been <N> weeks since the last patch
Maybe having triggers at reasonably fat M/N above (30/8?) would be enough
to trigger those conversations and keep momentum on releases while
respecting both the highly variable delta each change can have as well as
our variable resources to commit to release validation across the project
as contributors.
On Thu, Oct 17, 2019 at 8:23 AM Jon Haddad <j...@jonhaddad.com> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
