On Fri, Oct 18, 2019 at 12:30 AM Mick Semb Wever wrote:
>
>
> > 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
I agree with Mick. Those tickets have been open for a while, and I think
we're unlikely to resolve them in the next few days.
Since we're updating it anyways, I'll put mine in there too. Might as well
triple the number of active community members doing releases.
On Fri, Oct 18, 2019 at 1:30 AM M
> 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
> proble
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:
https://is
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/CASSA
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 the
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 th
+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 tha
> 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 technolo
