> 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
>
> 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
The migration is finished.
I had to fix a few things along the way. The docker containers didn't
build correctly (based on debian:latest rather than a fixed tag), and the
site had to be served out of the content directory rather than the publish
one we were using.
I'm going to address a couple
Oh! As an added bonus of migrating to proper bintray package repository
types, we also cure the pain of users attempting to install older
versions than the latest release, since all versions in the suite are
installable.
--
Michael
On 10/17/19 9:47 AM, Michael Shuler wrote:
Noted:
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
Thanks, Jon!
From: Jon Haddad
Sent: Thursday, October 17, 2019 7:07 AM
To: dev@cassandra.apache.org
Subject: Re: moving the site from SVN to git
The migration is finished.
I had to fix a few things along the way. The docker containers didn't
build
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
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 changes to the branch
3. it's been weeks since
+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
