hat one V5 ticket remains before the new protocol is finalized, that could
> be a reasonable compromise.
>
>I don't have especially strong feelings re: 15146 and 14825 and think
> these are reasonable candidates for deferral.
>
>__
gt; these are reasonable candidates for deferral.
>
> ____________________
> From: Joshua McKenzie
> Sent: Tuesday, June 16, 2020 4:08 PM
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Considering when to push tickets out of 4.0
>
16, 2020 4:08 PM
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Considering when to push tickets out of 4.0
I completely respect and agree with the need for a drumbeat to change our
culture around testing and quality; I also agree we haven't done much to
materia
and think these are
reasonable candidates for deferral.
From: Joshua McKenzie
Sent: Tuesday, June 16, 2020 4:08 PM
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Considering when to push tickets out of 4.0
I completely respect and agree with the need fo
I completely respect and agree with the need for a drumbeat to change our
culture around testing and quality; I also agree we haven't done much to
materially change that uniquely to 4.0. The 40_quality_testing epic is our
first step in that direction though I have some personal concerns about
leani
> Further, we have thousands of tests across all our suites
I think most here would agree that our testing remains inadequate, and that
this (modest, even in pure numerical terms for such a large project) number of
often poorly-written unit tests does not really change that fact.
Most of the pr
Inline
> On Jun 16, 2020, at 2:17 PM, Joshua McKenzie wrote:
>
>>
>> we still produce incorrect results as shown by CASSANDRA-15313; this is a
>> correctness issue, so must be a blocker for v5 protocol.
>
> That makes complete sense; I'd somehow missed the incorrect results aspect
> in trying
>
> we still produce incorrect results as shown by CASSANDRA-15313; this is a
> correctness issue, so must be a blocker for v5 protocol.
That makes complete sense; I'd somehow missed the incorrect results aspect
in trying to get context on the work. I'd be eager to hear about progress
on it as wel
So, if it helps matters: I am explicitly -1 the prior version of this work due
to the technical concerns expressed here and on the ticket. So we either need
to revert that patch or incorporate 15299.
On 16/06/2020, 21:48, "Mick Semb Wever" wrote:
>
> 2) Alternatively, it's been 3 yea
>
> 2) Alternatively, it's been 3 years, 4 months, 13 days since the release of
> 3.10.0 (the last time we added new features to the DB)
>
We did tick-tock, pushing feature releases too quickly, and without
supporting them for long enough to get stable. And then we've done "a la no
feature releas
inline
> On Jun 16, 2020, at 11:01 AM, Joshua McKenzie wrote:
>
>>
>> CASSANDRA-15299 - this should be a blocker for v5,
>
> Could you explain a little more about this? I'm missing context.
V5 added checksumming but had 2 main issues; lack of header checksum, and
checksum was on the decompre
>
> CASSANDRA-15299 - this should be a blocker for v5,
Could you explain a little more about this? I'm missing context.
punting these features don’t really get 4.0.0 released any faster.
GA, no. Beta, where we have a large call to arms to get broad user testing
and adoption in QA and dev enviro
CASSANDRA-15146 and CASSANDRA-14825 both can be rolled out and be backwards
compatible, so 4.0 vs 4.1 is fine to me
CASSANDRA-15299 - this should be a blocker for v5, so if this was punted out of
4.0 for any reason, we should also disable v5 protocol. About it being a
blocker for beta, since th
I wanted to open up a discussion about optionality of a few tickets for
4.0. The three I'm specifically thinking of here are:
1) CASSANDRA-15146: Transition TLS server configuration options are overly
complex
2) CASSANDRA-14825: Expose table schema for drivers
3) CASSANDRA-15299: CASSANDRA-13304 fo
14 matches
Mail list logo
