Hello Dev list,
I'm Chris Bradford a Product Manager at DataStax working with the
cass-operator team. For background, we started down the path of developing
an operator internally to power our C*aaS platform, Astra. Care was taken
from day 1 to keep anything specific to this product at a layer
Hi everyone,
I have the meeting video and transcripts uploaded:
https://cwiki.apache.org/confluence/display/CASSANDRA/2020-09-29+Apache+Cassandra+Contributor+Meeting+-+4.0+push+edition
Takeaways from today's meeting
- Shephards, shepherds shepherds. Quite a few places that no longer have a
> Isn't this hi-jacking the meaning (and value) of the "4.0-beta" and
"4.0-rc" fixVersion placeholders?
Makes sense, I hadn't thought of this. I retract my suggestion.
> Kinda agree with Josh here on what the epics should focus on. Personally,
because that better isolates and highlights what's
> I personally prefer to track fail/flaky tests as sub-issue of the 4.0 epic
> (CASSANDRA-15536) so we can track 4.0 completion status in a single place.
Strongly recommend against this approach. If we have hundreds of failing
upgrade tests (or even dozens) then we end up with a wild mix of
I personally prefer to track fail/flaky tests as sub-issue of the 4.0 epic
> (CASSANDRA-15536) so we can track 4.0 completion status in a single place.
>
> The way I see it is:
> * CASSANDRA-15536 epic: track everything that needs to be done to wrap-up
> 4.0 per macro component.
>
Isn't this
addendum: I understand the original way CASSANDRA-15536 was proposed is not
the way I'm describing, but it could be easily adaptable to that so we can
have a single place to track all tasks related to 4.0 quality and address
some of the visibility points raised by Mick.
Em ter., 29 de set. de
I personally prefer to track fail/flaky tests as sub-issue of the 4.0 epic
(CASSANDRA-15536) so we can track 4.0 completion status in a single place.
The way I see it is:
* CASSANDRA-15536 epic: track everything that needs to be done to wrap-up
4.0 per macro component.
* Kanban board: a different
Not that I know of. Perhaps we should add a new ticket to the quality epic
to track flakey and failing tests? (@cc Josh/Jordan)
Either a separate epic or a ticket w/sub-tasks either work well in terms of
organization. There's value in having one place to go to cleanly pull that
kind of work so I
Thanks for bringing up these valuable points, Mick! In fact we focused on
the quality epic so far but there is a lot more stuff unaddressed. I
commented some of the points you brought up below:
> How will we ensure this QA persists, so it's not a manual checklist
every release?
This is a great
> On 29 Sep 2020, at 09:50, Mick Semb Wever wrote:
>
>> Regarding the proposed agenda of going through the unassigned issues to
>> improve visibility on what needs to be done to ship 4.0 GA I think this is
>> a great start but only covers part of the problem.
>>
>> I think we have 3
> Regarding the proposed agenda of going through the unassigned issues to
> improve visibility on what needs to be done to ship 4.0 GA I think this is
> a great start but only covers part of the problem.
>
> I think we have 3 outstanding issues that are hampering visibility of 4.0
> progress:
> a)
11 matches
Mail list logo
