On CASSANDRA-15379, I think we would’ve discovered this issue during 4.0
testing and would have needed this bug fix anyway. We just caught it early
because you went ahead and tested the feature ;)
Dinesh
> On Mar 31, 2020, at 3:27 PM, Joseph Lynch wrote:
>
> On Tue, Mar 31, 2020 at 1:27 PM J
My PoV re: perf: if it's a regression or something that makes a new
feature just Not Work, mark it as bug.
All else mark improvement and can go in in patch rel.
On Tue, Mar 31, 2020 at 9:17 PM Jake Luciani wrote:
>
> I see what you mean, I guess my personal line is: does this work worse than
> t
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
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
wadays.
> >
> > I would be more than happy to help in any of these activities, too.
> >
> > Ekaterina
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> >
> >
> > > Begin forwarded message:
> > &
; > *From:* David Capwell
> > *Date:* 31 March 2020, 15:15:11 GMT-4
> > *To:* dev@cassandra.apache.org
> > *Subject:* *Re: Idea: Marking required scope for 4.0 GA vs. optional*
> > *Reply-To:* dev@cassandra.apache.org
> >
> > What I'm used to is havin
[1] https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> Begin forwarded message:
>
> *From:* David Capwell
> *Date:* 31 March 2020, 15:15:11 GMT-4
> *To:* dev@cassandra.apache.org
> *Subject:* *Re: Idea: Marking required scope for 4.0 GA vs. optional*
> *Repl
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
Regardless of how we indicate optional vs. required for rel, are there
strong opinions on who should set that metadata on tickets? Reporter?
Assignee? One person? A group of people?
On Sun, Mar 29, 2020 at 10:04 AM Joshua McKenzie
wrote:
> FWIW, I don't care what we go with as long as we can di
FWIW, I don't care what we go with as long as we can differentiate tickets
that are optional for the rel vs. tickets that are blockers and filter the
JIRA board on them so people know where they should focus their effort.
The rest of it's just paint colors to me.
On Sun, Mar 29, 2020 at 9:24 AM M
>
> Alternatively, we could revert to using 4.0.X or 4.X as we once did to
> indicate something is targeting a release vs. blocking on inclusion for it.
> That seems to be a more "project JIRA hackish idiom", and one that's
> historically been confusing for people. At least with a label it would be
t Andreas" wrote:
> >
> > Yep that makes sense to me.
> >
> > There's still much work to be done to exercise 4.0 builds to identify
> > unknown issues that haven't yet been filed – but those items can be
> tagged
> > as release blockers as
identify
> unknown issues that haven't yet been filed – but those items can be tagged
> as release blockers as they're identified. 👍
>
> ____________
> From: Joshua McKenzie
> Sent: Saturday, March 28, 2020 7:14 AM
> To: dev@cassandra.apache.org
> Subject: Idea: Ma
Sent: Saturday, March 28, 2020 7:14 AM
To: dev@cassandra.apache.org
Subject: Idea: Marking required scope for 4.0 GA vs. optional
As we're under a feature freeze but not code freeze, there are quite
reasonably tickets being opened for 4.0 (alpha, beta, or rc) that look
McKenzie
Sent: Saturday, March 28, 2020 7:14 AM
To: dev@cassandra.apache.org
Subject: Idea: Marking required scope for 4.0 GA vs. optional
As we're under a feature freeze but not code freeze, there are quite
reasonably tickets being opened for 4.0 (alpha, beta, or rc) that look like
nice to haves
As we're under a feature freeze but not code freeze, there are quite
reasonably tickets being opened for 4.0 (alpha, beta, or rc) that look like
nice to haves for the release but wouldn't necessarily block cutting GA. I
think there would be value in us flagging tickets that are required for 4.0
to
19 matches
Mail list logo
