Re: [DISCUSS] Next steps for Kubernetes operator SIG

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 abo

2020-09-29 Contributor Meeting

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 clea

Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

> 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 mi

Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

> 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 scop

Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

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 hi-j

Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

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 2020

Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

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

Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

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 h

Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

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 q

Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

> 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 outstandi

Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

> 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)