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
Yeah, the statement "we want to release ASAP" was quite scary to read. Did
I miss something? When do we cut GA? ASAP is like next week? What is going
on? Help! :D
On Sat, 28 Mar 2020 at 22:00, Joshua McKenzie wrote:
> >
> > since we want to release ASAP
> >
> Help me understand how to reconcile
>
> since we want to release ASAP
>
Help me understand how to reconcile this statement with the fact that
improvements and other nice-to-have optional tickets are being created and
worked on in even 4.0-alpha as recently as this past week. While *you* and
many others may want to release ASAP (inclu
I would personally prefer we simply bump tickets from the milestone
periodically. The point of a milestone is to collect tickets we expect to land
there, and since we want to release ASAP we should have at most a handful of
optional items there sponsored by some community members, so the burden
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 they're identified. 👍
From: Joshua McKenzie
Sent: Saturda
18 matches
Mail list logo
