As discussed, let's go with 16. Speaking with Anthony privately as well, I
had forgotten that some of the analysis that Branimir had initially done on
the skew and allocation may have been internal to DataStax so I should have
mentioned that previously. Thanks to Mick, Alex, and Anthony for doing
Sure. Let me figure out some timing and propose some times.
On Tue, Mar 31, 2020 at 5:15 PM Nate McCall wrote:
> Given the large portion of work that's been done in EU by the Orange folks
> vs. that of PST and APAC, I think this might be one for which we do two
> versions: PST morning and evenin
I see what you mean, I guess my personal line is: does this work worse than
the previous released version?
Seems like that's a yes in this case :)
On Tue, Mar 31, 2020 at 7:35 PM David Capwell wrote:
> One ticket I wanted to bring up is CASSANDRA-15566, this ticket is not a
> regression but it i
If the performance issue is a regression compared to 3.11 that makes total
sense.
And in the case of ZStd since that's new if its unusable without the
"improvement" then it also makes sense.
I think in both cases though it makes sense to classify these as
performance regression bugs.
I'll take a d
Given the large portion of work that's been done in EU by the Orange folks
vs. that of PST and APAC, I think this might be one for which we do two
versions: PST morning and evening.
On Wed, Apr 1, 2020 at 12:51 PM Patrick McFadin wrote:
> *Thanks for starting this thread Ben! Definitely agree th
Hello dev@cassandra, here is the state of 4.0 things.
Link to the JIRA board:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA
Josh has added a new 'Needs Attention' filter to show any tasks that
are stalled, need an assignee or need a reviewer. Makes it e
*Thanks for starting this thread Ben! Definitely agree that having a single
project-owned Kubernetes operator for Cassandra is preferred over a
fragmented ecosystem. I'll echo the same sentiment based on conversations
that it appears the community is eager to share experiences and
implementations i
One ticket I wanted to bring up is CASSANDRA-15566, this ticket is not a
regression but it is a critical bug. Personally I feel that only
regression should go into a freeze so I have a hard time justifying that
ticket right now (all known failure modes have been failing since at least
2.1). I gue
On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani wrote:
>
> Can we agree to move the improvements out to 4.0.x?
Generally I've been asked to put performance issues as improvements,
e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor
on real clusters without that patch, and therefore
An initial rough attempt to get together a queried view of outstanding
scope for "4.0 GA blockers" is here on this quick filter:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA&quickFilter=1719
JQL for a very similar query (pulls in about 10 more: catches s
I've been starting to look at the work left for 4.0 and was surprised to
see almost 1/2 the open tickets are Improvements.
Shouldn't the only criteria for 4.0 at this point should be bugs.
Can we agree to move the improvements out to 4.0.x?
-Jake
On Tue, Mar 31, 2020 at 4:02 PM Ekaterina Dimitro
Hello everyone,
I think the project might benefit of one "filter applied" now on the
current scope of JIRA tickets.
And then, regular triage so focus is not lost.
Up to now, I always try to look at the Release Lifecycle [1] criteria when
I open a new ticket in order to mark what is the target vers
On Tue, Mar 31, 2020 at 2:15 PM David Capwell wrote:
> Right now I don't see a active triage, but to Josh's point we would need to
> know who should first. Without answering, let me ask a question; should I
> (non committer) be adding blockers?
If you like, yes. I don't think anyone, committer o
What I'm used to is having two buckets for a release: tickets in the
release (if not complete they are blockers), and triage. How this is done
isn't important but I do feel it's important to have both.
Right now I don't see a active triage, but to Josh's point we would need to
know who should firs
Hi Ben!
Totally agree. We should collaborate on a unified operator and I think as
deployment on k8s becomes more and more prevalent we need to have
distributed testing in k8s.
To that end we are working on OSS releasing our distributed testing service
we've developed over the years to make this
15 matches
Mail list logo
