You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Patrick McFadin <pm...@gmail.com> on 2020/09/25 00:23:00 UTC
Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Hi everyone,
First, I want to acknowledge some of the raw conversations today in the
cassandra-dev slack channel. It was probably well overdue and if not for
2020 and what a wonderful year this has been, we might have gotten there
earlier. I really appreciate how everyone who participated kept the
conversation from completely devolving into something that wouldn't get us
anywhere as a project. I also want to say that I hope we don't forget to
pause and give each other a break. People are already tense and on edge
from months of pandemics, politics, social unrest, disasters, child care
issues and a lot of other things on a long list. I find it helpful to
assume that everyone I talk to is stressed out, behind schedule and
probably has a boss pressuring them to do something. We share a really
unique common bond by willfully choosing to work on distributed systems. I
hope we find more reasons to come together than be apart in the future.
If I can even attempt to sum up the important themes from a very long
conversation. There is a tension between the frozen codebase leading to 4.0
and the desire to add new features beyond 4.0. One way to eliminate that
tension is to get 4.0 wrapped up. What is left to get 4.0 done isn't clear
to many and there is a desire to get clear on the remaining items.
I would like to contribute some of my energy and time to help this along.
Standing on the shoulders of giants here, a LOT of work has already gone
into this topic. Josh, Jordan and Jon (J^3 ?) kept a steady strain on
updating jiras and status. This Kanban is really helpful:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661
There is an epic that was discussed in slack:
https://issues.apache.org/jira/browse/CASSANDRA-15536
There are 17 separate jiras as dependencies, of which only 2 are marked as
completed. 3 have no assigned owner. I have put a Zoom call on the
contributor meeting calendar to discuss those three first. I had to weave
it between ApacheCon sessions but hopefully this will help in velocity. Agenda
posted, feel free to alter as you see fit. September 29, 1230PM PST:
https://cwiki.apache.org/confluence/display/CASSANDRA/2020-09-29+Apache+Cassandra+Contributor+Meeting+-+4.0+push+edition
I mentioned this is Slack. We are so close. Beta 2 is out there, Harry just
dropped and Jiras have been closing. I get excited when I think of the
impact this will have. My entire life has now somehow become dependent on
Cassandra working. When I take a pic with my iPhone. Play games on my
PlayStation. Use curb-side pickup at Target. Order food on GrubHub.
Everybody here helped make that happen and there are a lot of great
engineers that will be deploying 4.0 and loving it. Most importantly, I
reliably get food when I'm playing Ghost of Tsushima and take a selfie for
my finsta. #priorities I would love to stick it to 2020 and make "Shipping
4.0" a positive event as we leave this stinking year behind.
Patrick
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Patrick McFadin <pm...@gmail.com>.
Hi Alex,
This is an attempt to manage the tyranny of timezones with a worldwide
community. That time is what gives New Zealand and Australia at least a
chance to attend that isn't the middle of the night. The alternative would
be to have two meetings for different timezones.
Patrick
On Fri, Sep 25, 2020 at 2:07 AM Oleksandr Petrov <ol...@gmail.com>
wrote:
> Is it possible to find a time slot that is earlier than 12:30PM PST? It's
> 9:30PM for most of Europe [1], and this meeting is rather important for
> many of us to attend.
>
> [1] https://savvytime.com/converter/pst-to-sgt-cet-gmt/12-30pm
>
> On Fri, Sep 25, 2020 at 2:23 AM Patrick McFadin <pm...@gmail.com>
> wrote:
>
> > Hi everyone,
> >
> > First, I want to acknowledge some of the raw conversations today in the
> > cassandra-dev slack channel. It was probably well overdue and if not for
> > 2020 and what a wonderful year this has been, we might have gotten there
> > earlier. I really appreciate how everyone who participated kept the
> > conversation from completely devolving into something that wouldn't get
> us
> > anywhere as a project. I also want to say that I hope we don't forget to
> > pause and give each other a break. People are already tense and on edge
> > from months of pandemics, politics, social unrest, disasters, child care
> > issues and a lot of other things on a long list. I find it helpful to
> > assume that everyone I talk to is stressed out, behind schedule and
> > probably has a boss pressuring them to do something. We share a really
> > unique common bond by willfully choosing to work on distributed systems.
> I
> > hope we find more reasons to come together than be apart in the future.
> >
> > If I can even attempt to sum up the important themes from a very long
> > conversation. There is a tension between the frozen codebase leading to
> 4.0
> > and the desire to add new features beyond 4.0. One way to eliminate that
> > tension is to get 4.0 wrapped up. What is left to get 4.0 done isn't
> clear
> > to many and there is a desire to get clear on the remaining items.
> >
> > I would like to contribute some of my energy and time to help this along.
> > Standing on the shoulders of giants here, a LOT of work has already gone
> > into this topic. Josh, Jordan and Jon (J^3 ?) kept a steady strain on
> > updating jiras and status. This Kanban is really helpful:
> >
> >
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661
> >
> > There is an epic that was discussed in slack:
> > https://issues.apache.org/jira/browse/CASSANDRA-15536
> >
> > There are 17 separate jiras as dependencies, of which only 2 are marked
> as
> > completed. 3 have no assigned owner. I have put a Zoom call on the
> > contributor meeting calendar to discuss those three first. I had to weave
> > it between ApacheCon sessions but hopefully this will help in velocity.
> > Agenda
> > posted, feel free to alter as you see fit. September 29, 1230PM PST:
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/2020-09-29+Apache+Cassandra+Contributor+Meeting+-+4.0+push+edition
> >
> > I mentioned this is Slack. We are so close. Beta 2 is out there, Harry
> just
> > dropped and Jiras have been closing. I get excited when I think of the
> > impact this will have. My entire life has now somehow become dependent on
> > Cassandra working. When I take a pic with my iPhone. Play games on my
> > PlayStation. Use curb-side pickup at Target. Order food on GrubHub.
> > Everybody here helped make that happen and there are a lot of great
> > engineers that will be deploying 4.0 and loving it. Most importantly, I
> > reliably get food when I'm playing Ghost of Tsushima and take a selfie
> for
> > my finsta. #priorities I would love to stick it to 2020 and make
> "Shipping
> > 4.0" a positive event as we leave this stinking year behind.
> >
> > Patrick
> >
>
>
> --
> alex p
>
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Oleksandr Petrov <ol...@gmail.com>.
Is it possible to find a time slot that is earlier than 12:30PM PST? It's
9:30PM for most of Europe [1], and this meeting is rather important for
many of us to attend.
[1] https://savvytime.com/converter/pst-to-sgt-cet-gmt/12-30pm
On Fri, Sep 25, 2020 at 2:23 AM Patrick McFadin <pm...@gmail.com> wrote:
> Hi everyone,
>
> First, I want to acknowledge some of the raw conversations today in the
> cassandra-dev slack channel. It was probably well overdue and if not for
> 2020 and what a wonderful year this has been, we might have gotten there
> earlier. I really appreciate how everyone who participated kept the
> conversation from completely devolving into something that wouldn't get us
> anywhere as a project. I also want to say that I hope we don't forget to
> pause and give each other a break. People are already tense and on edge
> from months of pandemics, politics, social unrest, disasters, child care
> issues and a lot of other things on a long list. I find it helpful to
> assume that everyone I talk to is stressed out, behind schedule and
> probably has a boss pressuring them to do something. We share a really
> unique common bond by willfully choosing to work on distributed systems. I
> hope we find more reasons to come together than be apart in the future.
>
> If I can even attempt to sum up the important themes from a very long
> conversation. There is a tension between the frozen codebase leading to 4.0
> and the desire to add new features beyond 4.0. One way to eliminate that
> tension is to get 4.0 wrapped up. What is left to get 4.0 done isn't clear
> to many and there is a desire to get clear on the remaining items.
>
> I would like to contribute some of my energy and time to help this along.
> Standing on the shoulders of giants here, a LOT of work has already gone
> into this topic. Josh, Jordan and Jon (J^3 ?) kept a steady strain on
> updating jiras and status. This Kanban is really helpful:
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661
>
> There is an epic that was discussed in slack:
> https://issues.apache.org/jira/browse/CASSANDRA-15536
>
> There are 17 separate jiras as dependencies, of which only 2 are marked as
> completed. 3 have no assigned owner. I have put a Zoom call on the
> contributor meeting calendar to discuss those three first. I had to weave
> it between ApacheCon sessions but hopefully this will help in velocity.
> Agenda
> posted, feel free to alter as you see fit. September 29, 1230PM PST:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/2020-09-29+Apache+Cassandra+Contributor+Meeting+-+4.0+push+edition
>
> I mentioned this is Slack. We are so close. Beta 2 is out there, Harry just
> dropped and Jiras have been closing. I get excited when I think of the
> impact this will have. My entire life has now somehow become dependent on
> Cassandra working. When I take a pic with my iPhone. Play games on my
> PlayStation. Use curb-side pickup at Target. Order food on GrubHub.
> Everybody here helped make that happen and there are a lot of great
> engineers that will be deploying 4.0 and loving it. Most importantly, I
> reliably get food when I'm playing Ghost of Tsushima and take a selfie for
> my finsta. #priorities I would love to stick it to 2020 and make "Shipping
> 4.0" a positive event as we leave this stinking year behind.
>
> Patrick
>
--
alex p
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Paulo Motta <pa...@gmail.com>.
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 às 11:07, Paulo Motta <pa...@gmail.com>
escreveu:
> 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 view of CASSANDRA-15536, but all issues in the
> Kanban should be ultimately tied to a sub-issue on CASSANDRA-15536.
> * Component sub-issues: both "new ways to test" + "bugs related to the
> component"
> * Test failure sub-issue: group test failures/flakies from any components.
>
> What do you think?
>
> Em ter., 29 de set. de 2020 às 10:47, Josh McKenzie <jm...@apache.org>
> escreveu:
>
>> 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 have a slight bias towards an independent epic for 4.0
>> test *fixing* instead of mixing the "new ways to test" with "cleaning up
>> the testing ways we know".
>>
>> ---
>> Josh McKenzie
>>
>>
>>
>> On Tue, Sep 29, 2020 at 8:34 AM, Paulo Motta <pa...@gmail.com>
>> wrote:
>>
>> > 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 question but I believe it warrants a separate discussion
>> > as part of a larger discussion on improving our development/quality
>> process
>> > post-4.0.
>> >
>> > *** CASSANDRA-15234 – Standardise config and JVM parameters - It looks
>> >
>> > like we have dropped the ball on this.
>> >
>> > It's sad that we dropped the ball on this important change but now I
>> think
>> > it's too late to make these changes as it will bring entropy towards
>> > stabilizing 4.0. In that sense I think we should postpone this to the
>> next
>> > major and prioritize it earlier in the next cycle.
>> >
>> > Do all remaining flakey and failing units and dtests have jira tickets
>> >
>> > entered for 4.0-beta? Has the same been done, at least with rough
>> > grouping, for the upgrade tests? Are these tied to the testing epics in
>> any
>> > way?
>> >
>> > 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)
>> >
>> > Has any triage efforts happened here?
>> >
>> > Not that I know of but maybe Josh/Jordan/Jon (J^3) are planning on
>> looking
>> > at it. I can take a stab at triaging some of these tickets.
>> >
>> > Do triaged bugs in this list get moved to fix version "4.x" ?
>> >
>> > I think in the spirit of expediting 4.0RC release we should mark bugs
>> with
>> > low severity (ie. those with a simple workaround) to 4.0.1. Any bug with
>> > medium-high severity should be marked as 4.0-rc to favor stability.
>> >
>> > Are we duplicating efforts in the testing epics when others have already
>> >
>> > identified and reported the bugs but we just haven't triage them?
>> >
>> > That's a good point. I think as part of the triaging effort we should
>> link
>> > the bugs to existing quality epics so we can keep track of them.
>> >
>> > Em ter., 29 de set. de 2020 às 06:11, Sam Tunnicliffe <sa...@beobal.com>
>> > escreveu:
>> >
>> > On 29 Sep 2020, at 09:50, Mick Semb Wever <mc...@apache.org> 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 outstanding issues that are hampering visibility of
>> >
>> > 4.0
>> >
>> > progress:
>> > a) Quality testing issues with no shepherd;
>> > b) Quality testing issues with shepherd, but no recent activity (~2
>> >
>> > months
>> >
>> > or less);
>> > c) Quality testing issues with no objective acceptance
>> >
>> > criteria/Definition
>> >
>> > of Done;
>> >
>> > These Quality testing epics are a great focal point. How will we ensure
>> > this QA persists, so it's not a manual checklist every release?
>> >
>> > The following is what I can see outstanding for the 4.0 release, that is
>> > not afaik attached to these epic tickets…
>> >
>> > ** Those issues that slipped alpha…
>> > *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming
>> and
>> > compression in protocol v5-beta
>> > *** CASSANDRA-15234 – Standardise config and JVM parameters
>> > *** CASSANDRA-13701 – Lower default num_tokens (blocked by
>> > 'CASSANDRA-16079 Improve dtest runtime' )
>> > ** 95 jira tickets in 4.0-beta and 4.0-rc
>> > ** 631 jira bug tickets with no assigned "fix version"
>> > ** Remaining flakey unit and dtests
>> > ** Hundreds of failing and flakey upgrade dtests
>> > ** Reports from driver tests, and other external test systems
>> > ** Reports and/or integration with Fallout and Harry
>> >
>> > In a bit more detail…
>> >
>> > *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming
>> and
>> > compression in protocol v5-beta
>> >
>> > This looks like it is in its final patch and review. Is that correct
>> Sam?
>> >
>> > Yes it is. I hope to get review finished and post some further perf
>> > numbers this week.
>> >
>> > *** CASSANDRA-15234 – Standardise config and JVM parameters
>> >
>> > It looks like we have dropped the ball on this.
>> >
>> > *** CASSANDRA-13701 – Lower default num_tokens, and CASSANDRA-16079
>> >
>> > Some effort is undergoing from Ekaterina, David, and myself. I've put
>> > together a prototype for caching bootstrapped ccm clusters, but i'm not
>> yet
>> > sure I can get much savings over the current tests and only a minimal
>> > saving off the 13701 patch. Berenguer brought up that 40% of the dtests
>> are
>> > single-node, their performance not changed by 13701, and probably better
>> > off rewritten to in-jvm tests.
>> >
>> > ** 95 jira tickets in 4.0-beta and 4.0-rc
>> > ** Remaining flakey unit and dtests
>> > ** Hundreds of failing and flakey upgrade dtests
>> >
>> > Do all remaining flakey and failing units and dtests have jira tickets
>> > entered for 4.0-beta?
>> > Has the same been done, at least with rough grouping, for the upgrade
>> >
>> > tests?
>> >
>> > Are these tied to the testing epics in any way?
>> >
>> > ** 631 jira bug tickets with no assigned "fix version" (who knows how
>> >
>> > many
>> >
>> > of these are applicable to 4.0?)
>> >
>> > Has any triage efforts happened here?
>> > Do triaged bugs in this list get moved to fix version "4.x" ? Are we
>> > duplicating efforts in the testing epics when others have already
>> > identified and reported the bugs but we just haven't triage them?
>> >
>> > --------------------------------------------------------------------- To
>> > unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org For
>> additional
>> > commands, e-mail: dev-help@cassandra.apache.org
>> >
>> >
>>
>
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Mick Semb Wever <mc...@apache.org>.
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-jacking the meaning (and value) of the "4.0-beta" and
"4.0-rc" fixVersion placeholders?
My understanding is that nothing should be set to fixVersion "4.0-beta" if
it is not a blocker to 4.0-rc. And likewise nothing is set to "4.0-rc"
unless it is a blocker to 4.0-GA. i.e. these were not wishlist placeholders.
Of course folk are still free to "scratch their itch" and review and merge
the non-blocker bugs from "4.x", so long as all release lifecycle concerns
are met.
Kinda agree with Josh here on what the epics should focus on. Personally,
because that better isolates and highlights what's missing from continuous
and automated QA post-4.0, looping back to my first question and concern.
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Paulo Motta <pa...@gmail.com>.
> 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 missing from continuous
and automated QA post-4.0, looping back to my first question and concern.
+1
> I thought you were suggesting we do test failures as sub-tasks on a
ticket in 15536 which could work. But having them children of 15536 is just
going to make that noisy enough as to be not useful.
I was actually advocating for the former but I agree we should restrict the
scope of CASSANDRA-15536 single epic.to new improvements as you suggested
and Mick concurred.
> I'd recommend we rely on JQL for the release scope and kanban board it
for visibility based on fixversion to have our "single pane of glass" for
4.0 progress.
+1
With that said, I think it could be beneficial for visibility to track
flaky/test failures blocking 4.0 on a single epic with fixversion 4.0-rc.
Em ter., 29 de set. de 2020 às 11:38, Joshua McKenzie <
joshua.mckenzie@gmail.com> escreveu:
> > 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 scope in
> one epic. Some things 1 day tasks (fix a test), other things multi-week or
> month efforts (scope and build tests for area X).
>
> I thought you were suggesting we do test failures as sub-tasks on a ticket
> in 15536 which could work. But having them children of 15536 is just going
> to make that noisy enough as to be not useful.
>
> I'd recommend we rely on JQL for the release scope and kanban board it for
> visibility based on fixversion to have our "single pane of glass" for 4.0
> progress.
>
> --
> Joshua McKenzie
>
> On Tue, Sep 29, 2020 at 10:07 AM, Paulo Motta < pauloricardomg@gmail.com
> > wrote:
>
> >
> >
> >
> > 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 view of CASSANDRA-15536, but all issues in
> the
> > Kanban should be ultimately tied to a sub-issue on CASSANDRA-15536.
> > * Component sub-issues: both "new ways to test" + "bugs related to the
> > component"
> > * Test failure sub-issue: group test failures/flakies from any
> components.
> >
> >
> >
> >
> > What do you think?
> >
> >
> >
> > Em ter., 29 de set. de 2020 às 10:47, Josh McKenzie < jmckenzie@
> apache. org
> > ( jmckenzie@apache.org ) > escreveu:
> >
> >
> >>
> >>
> >> 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 have a slight bias towards an independent epic
> for
> >> 4.0 test *fixing* instead of mixing the "new ways to test" with
> "cleaning
> >> up the testing ways we know".
> >>
> >>
> >>
> >> ---
> >> Josh McKenzie
> >>
> >>
> >>
> >> On Tue, Sep 29, 2020 at 8:34 AM, Paulo Motta < pauloricardomg@ gmail.
> com (
> >> pauloricardomg@gmail.com ) > wrote:
> >>
> >>
> >>>
> >>>
> >>> 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 question but I believe it warrants a separate
> discussion
> >>> as part of a larger discussion on improving our development/quality
> >>>
> >>>
> >>
> >>
> >>
> >> process
> >>
> >>
> >>>
> >>>
> >>> post-4.0.
> >>>
> >>>
> >>>
> >>> *** CASSANDRA-15234 – Standardise config and JVM parameters - It looks
> >>>
> >>>
> >>>
> >>> like we have dropped the ball on this.
> >>>
> >>>
> >>>
> >>> It's sad that we dropped the ball on this important change but now I
> >>>
> >>>
> >>
> >>
> >>
> >> think
> >>
> >>
> >>>
> >>>
> >>> it's too late to make these changes as it will bring entropy towards
> >>> stabilizing 4.0. In that sense I think we should postpone this to the
> >>>
> >>>
> >>
> >>
> >>
> >> next
> >>
> >>
> >>>
> >>>
> >>> major and prioritize it earlier in the next cycle.
> >>>
> >>>
> >>>
> >>> Do all remaining flakey and failing units and dtests have jira tickets
> >>>
> >>>
> >>>
> >>> entered for 4.0-beta? Has the same been done, at least with rough
> >>> grouping, for the upgrade tests? Are these tied to the testing epics in
> >>>
> >>>
> >>
> >>
> >>
> >> any
> >>
> >>
> >>>
> >>>
> >>> way?
> >>>
> >>>
> >>>
> >>> 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)
> >>>
> >>>
> >>>
> >>> Has any triage efforts happened here?
> >>>
> >>>
> >>>
> >>> Not that I know of but maybe Josh/Jordan/Jon (J^3) are planning on
> >>>
> >>>
> >>
> >>
> >>
> >> looking
> >>
> >>
> >>>
> >>>
> >>> at it. I can take a stab at triaging some of these tickets.
> >>>
> >>>
> >>>
> >>> Do triaged bugs in this list get moved to fix version "4.x" ?
> >>>
> >>>
> >>>
> >>> I think in the spirit of expediting 4.0RC release we should mark bugs
> >>>
> >>>
> >>
> >>
> >>
> >> with
> >>
> >>
> >>>
> >>>
> >>> low severity (ie. those with a simple workaround) to 4.0.1. Any bug
> with
> >>> medium-high severity should be marked as 4.0-rc to favor stability.
> >>>
> >>>
> >>>
> >>> Are we duplicating efforts in the testing epics when others have
> already
> >>>
> >>>
> >>>
> >>> identified and reported the bugs but we just haven't triage them?
> >>>
> >>>
> >>>
> >>> That's a good point. I think as part of the triaging effort we should
> >>>
> >>>
> >>
> >>
> >>
> >> link
> >>
> >>
> >>>
> >>>
> >>> the bugs to existing quality epics so we can keep track of them.
> >>>
> >>>
> >>>
> >>> Em ter., 29 de set. de 2020 às 06:11, Sam Tunnicliffe < sam@ beobal.
> com (
> >>> sam@beobal.com ) > escreveu:
> >>>
> >>>
> >>>
> >>> On 29 Sep 2020, at 09:50, Mick Semb Wever < mck@ apache. org (
> >>> mck@apache.org ) > 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 outstanding issues that are hampering visibility of
> >>>
> >>>
> >>>
> >>> 4.0
> >>>
> >>>
> >>>
> >>> progress:
> >>> a) Quality testing issues with no shepherd;
> >>> b) Quality testing issues with shepherd, but no recent activity (~2
> >>>
> >>>
> >>>
> >>> months
> >>>
> >>>
> >>>
> >>> or less);
> >>> c) Quality testing issues with no objective acceptance
> >>>
> >>>
> >>>
> >>> criteria/Definition
> >>>
> >>>
> >>>
> >>> of Done;
> >>>
> >>>
> >>>
> >>> These Quality testing epics are a great focal point. How will we ensure
> >>> this QA persists, so it's not a manual checklist every release?
> >>>
> >>>
> >>>
> >>> The following is what I can see outstanding for the 4.0 release, that
> is
> >>> not afaik attached to these epic tickets…
> >>>
> >>>
> >>>
> >>> ** Those issues that slipped alpha…
> >>> *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming
> and
> >>> compression in protocol v5-beta
> >>> *** CASSANDRA-15234 – Standardise config and JVM parameters
> >>> *** CASSANDRA-13701 – Lower default num_tokens (blocked by
> >>> 'CASSANDRA-16079 Improve dtest runtime' )
> >>> ** 95 jira tickets in 4.0-beta and 4.0-rc
> >>> ** 631 jira bug tickets with no assigned "fix version"
> >>> ** Remaining flakey unit and dtests
> >>> ** Hundreds of failing and flakey upgrade dtests
> >>> ** Reports from driver tests, and other external test systems
> >>> ** Reports and/or integration with Fallout and Harry
> >>>
> >>>
> >>>
> >>> In a bit more detail…
> >>>
> >>>
> >>>
> >>> *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming
> and
> >>> compression in protocol v5-beta
> >>>
> >>>
> >>>
> >>> This looks like it is in its final patch and review. Is that correct
> Sam?
> >>>
> >>>
> >>>
> >>> Yes it is. I hope to get review finished and post some further perf
> >>> numbers this week.
> >>>
> >>>
> >>>
> >>> *** CASSANDRA-15234 – Standardise config and JVM parameters
> >>>
> >>>
> >>>
> >>> It looks like we have dropped the ball on this.
> >>>
> >>>
> >>>
> >>> *** CASSANDRA-13701 – Lower default num_tokens, and CASSANDRA-16079
> >>>
> >>>
> >>>
> >>> Some effort is undergoing from Ekaterina, David, and myself. I've put
> >>> together a prototype for caching bootstrapped ccm clusters, but i'm not
> >>>
> >>>
> >>
> >>
> >>
> >> yet
> >>
> >>
> >>>
> >>>
> >>> sure I can get much savings over the current tests and only a minimal
> >>> saving off the 13701 patch. Berenguer brought up that 40% of the dtests
> >>>
> >>>
> >>
> >>
> >>
> >> are
> >>
> >>
> >>>
> >>>
> >>> single-node, their performance not changed by 13701, and probably
> better
> >>> off rewritten to in-jvm tests.
> >>>
> >>>
> >>>
> >>> ** 95 jira tickets in 4.0-beta and 4.0-rc
> >>> ** Remaining flakey unit and dtests
> >>> ** Hundreds of failing and flakey upgrade dtests
> >>>
> >>>
> >>>
> >>> Do all remaining flakey and failing units and dtests have jira tickets
> >>> entered for 4.0-beta?
> >>> Has the same been done, at least with rough grouping, for the upgrade
> >>>
> >>>
> >>>
> >>> tests?
> >>>
> >>>
> >>>
> >>> Are these tied to the testing epics in any way?
> >>>
> >>>
> >>>
> >>> ** 631 jira bug tickets with no assigned "fix version" (who knows how
> >>>
> >>>
> >>>
> >>> many
> >>>
> >>>
> >>>
> >>> of these are applicable to 4.0?)
> >>>
> >>>
> >>>
> >>> Has any triage efforts happened here?
> >>> Do triaged bugs in this list get moved to fix version "4.x" ? Are we
> >>> duplicating efforts in the testing epics when others have already
> >>> identified and reported the bugs but we just haven't triage them?
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> To
> >>> unsubscribe, e-mail: dev-unsubscribe@ cassandra. apache. org (
> >>> dev-unsubscribe@cassandra.apache.org ) For additional commands,
> e-mail: dev-help@
> >>> cassandra. apache. org ( dev-help@cassandra.apache.org )
> >>>
> >>>
> >>
> >>
> >
> >
> >
Re: Cassandra Contributor Meeting to focus on outstanding 4.0
issues
Posted by Joshua McKenzie <jo...@gmail.com>.
> 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 scope in one epic. Some things 1 day tasks (fix a test), other things multi-week or month efforts (scope and build tests for area X).
I thought you were suggesting we do test failures as sub-tasks on a ticket in 15536 which could work. But having them children of 15536 is just going to make that noisy enough as to be not useful.
I'd recommend we rely on JQL for the release scope and kanban board it for visibility based on fixversion to have our "single pane of glass" for 4.0 progress.
--
Joshua McKenzie
On Tue, Sep 29, 2020 at 10:07 AM, Paulo Motta < pauloricardomg@gmail.com > wrote:
>
>
>
> 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 view of CASSANDRA-15536, but all issues in the
> Kanban should be ultimately tied to a sub-issue on CASSANDRA-15536.
> * Component sub-issues: both "new ways to test" + "bugs related to the
> component"
> * Test failure sub-issue: group test failures/flakies from any components.
>
>
>
>
> What do you think?
>
>
>
> Em ter., 29 de set. de 2020 às 10:47, Josh McKenzie < jmckenzie@ apache. org
> ( jmckenzie@apache.org ) > escreveu:
>
>
>>
>>
>> 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 have a slight bias towards an independent epic for
>> 4.0 test *fixing* instead of mixing the "new ways to test" with "cleaning
>> up the testing ways we know".
>>
>>
>>
>> ---
>> Josh McKenzie
>>
>>
>>
>> On Tue, Sep 29, 2020 at 8:34 AM, Paulo Motta < pauloricardomg@ gmail. com (
>> pauloricardomg@gmail.com ) > wrote:
>>
>>
>>>
>>>
>>> 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 question but I believe it warrants a separate discussion
>>> as part of a larger discussion on improving our development/quality
>>>
>>>
>>
>>
>>
>> process
>>
>>
>>>
>>>
>>> post-4.0.
>>>
>>>
>>>
>>> *** CASSANDRA-15234 – Standardise config and JVM parameters - It looks
>>>
>>>
>>>
>>> like we have dropped the ball on this.
>>>
>>>
>>>
>>> It's sad that we dropped the ball on this important change but now I
>>>
>>>
>>
>>
>>
>> think
>>
>>
>>>
>>>
>>> it's too late to make these changes as it will bring entropy towards
>>> stabilizing 4.0. In that sense I think we should postpone this to the
>>>
>>>
>>
>>
>>
>> next
>>
>>
>>>
>>>
>>> major and prioritize it earlier in the next cycle.
>>>
>>>
>>>
>>> Do all remaining flakey and failing units and dtests have jira tickets
>>>
>>>
>>>
>>> entered for 4.0-beta? Has the same been done, at least with rough
>>> grouping, for the upgrade tests? Are these tied to the testing epics in
>>>
>>>
>>
>>
>>
>> any
>>
>>
>>>
>>>
>>> way?
>>>
>>>
>>>
>>> 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)
>>>
>>>
>>>
>>> Has any triage efforts happened here?
>>>
>>>
>>>
>>> Not that I know of but maybe Josh/Jordan/Jon (J^3) are planning on
>>>
>>>
>>
>>
>>
>> looking
>>
>>
>>>
>>>
>>> at it. I can take a stab at triaging some of these tickets.
>>>
>>>
>>>
>>> Do triaged bugs in this list get moved to fix version "4.x" ?
>>>
>>>
>>>
>>> I think in the spirit of expediting 4.0RC release we should mark bugs
>>>
>>>
>>
>>
>>
>> with
>>
>>
>>>
>>>
>>> low severity (ie. those with a simple workaround) to 4.0.1. Any bug with
>>> medium-high severity should be marked as 4.0-rc to favor stability.
>>>
>>>
>>>
>>> Are we duplicating efforts in the testing epics when others have already
>>>
>>>
>>>
>>> identified and reported the bugs but we just haven't triage them?
>>>
>>>
>>>
>>> That's a good point. I think as part of the triaging effort we should
>>>
>>>
>>
>>
>>
>> link
>>
>>
>>>
>>>
>>> the bugs to existing quality epics so we can keep track of them.
>>>
>>>
>>>
>>> Em ter., 29 de set. de 2020 às 06:11, Sam Tunnicliffe < sam@ beobal. com (
>>> sam@beobal.com ) > escreveu:
>>>
>>>
>>>
>>> On 29 Sep 2020, at 09:50, Mick Semb Wever < mck@ apache. org (
>>> mck@apache.org ) > 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 outstanding issues that are hampering visibility of
>>>
>>>
>>>
>>> 4.0
>>>
>>>
>>>
>>> progress:
>>> a) Quality testing issues with no shepherd;
>>> b) Quality testing issues with shepherd, but no recent activity (~2
>>>
>>>
>>>
>>> months
>>>
>>>
>>>
>>> or less);
>>> c) Quality testing issues with no objective acceptance
>>>
>>>
>>>
>>> criteria/Definition
>>>
>>>
>>>
>>> of Done;
>>>
>>>
>>>
>>> These Quality testing epics are a great focal point. How will we ensure
>>> this QA persists, so it's not a manual checklist every release?
>>>
>>>
>>>
>>> The following is what I can see outstanding for the 4.0 release, that is
>>> not afaik attached to these epic tickets…
>>>
>>>
>>>
>>> ** Those issues that slipped alpha…
>>> *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
>>> compression in protocol v5-beta
>>> *** CASSANDRA-15234 – Standardise config and JVM parameters
>>> *** CASSANDRA-13701 – Lower default num_tokens (blocked by
>>> 'CASSANDRA-16079 Improve dtest runtime' )
>>> ** 95 jira tickets in 4.0-beta and 4.0-rc
>>> ** 631 jira bug tickets with no assigned "fix version"
>>> ** Remaining flakey unit and dtests
>>> ** Hundreds of failing and flakey upgrade dtests
>>> ** Reports from driver tests, and other external test systems
>>> ** Reports and/or integration with Fallout and Harry
>>>
>>>
>>>
>>> In a bit more detail…
>>>
>>>
>>>
>>> *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
>>> compression in protocol v5-beta
>>>
>>>
>>>
>>> This looks like it is in its final patch and review. Is that correct Sam?
>>>
>>>
>>>
>>> Yes it is. I hope to get review finished and post some further perf
>>> numbers this week.
>>>
>>>
>>>
>>> *** CASSANDRA-15234 – Standardise config and JVM parameters
>>>
>>>
>>>
>>> It looks like we have dropped the ball on this.
>>>
>>>
>>>
>>> *** CASSANDRA-13701 – Lower default num_tokens, and CASSANDRA-16079
>>>
>>>
>>>
>>> Some effort is undergoing from Ekaterina, David, and myself. I've put
>>> together a prototype for caching bootstrapped ccm clusters, but i'm not
>>>
>>>
>>
>>
>>
>> yet
>>
>>
>>>
>>>
>>> sure I can get much savings over the current tests and only a minimal
>>> saving off the 13701 patch. Berenguer brought up that 40% of the dtests
>>>
>>>
>>
>>
>>
>> are
>>
>>
>>>
>>>
>>> single-node, their performance not changed by 13701, and probably better
>>> off rewritten to in-jvm tests.
>>>
>>>
>>>
>>> ** 95 jira tickets in 4.0-beta and 4.0-rc
>>> ** Remaining flakey unit and dtests
>>> ** Hundreds of failing and flakey upgrade dtests
>>>
>>>
>>>
>>> Do all remaining flakey and failing units and dtests have jira tickets
>>> entered for 4.0-beta?
>>> Has the same been done, at least with rough grouping, for the upgrade
>>>
>>>
>>>
>>> tests?
>>>
>>>
>>>
>>> Are these tied to the testing epics in any way?
>>>
>>>
>>>
>>> ** 631 jira bug tickets with no assigned "fix version" (who knows how
>>>
>>>
>>>
>>> many
>>>
>>>
>>>
>>> of these are applicable to 4.0?)
>>>
>>>
>>>
>>> Has any triage efforts happened here?
>>> Do triaged bugs in this list get moved to fix version "4.x" ? Are we
>>> duplicating efforts in the testing epics when others have already
>>> identified and reported the bugs but we just haven't triage them?
>>>
>>>
>>>
>>> --------------------------------------------------------------------- To
>>> unsubscribe, e-mail: dev-unsubscribe@ cassandra. apache. org (
>>> dev-unsubscribe@cassandra.apache.org ) For additional commands, e-mail: dev-help@
>>> cassandra. apache. org ( dev-help@cassandra.apache.org )
>>>
>>>
>>
>>
>
>
>
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Paulo Motta <pa...@gmail.com>.
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 view of CASSANDRA-15536, but all issues in the
Kanban should be ultimately tied to a sub-issue on CASSANDRA-15536.
* Component sub-issues: both "new ways to test" + "bugs related to the
component"
* Test failure sub-issue: group test failures/flakies from any components.
What do you think?
Em ter., 29 de set. de 2020 às 10:47, Josh McKenzie <jm...@apache.org>
escreveu:
> 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 have a slight bias towards an independent epic for 4.0
> test *fixing* instead of mixing the "new ways to test" with "cleaning up
> the testing ways we know".
>
> ---
> Josh McKenzie
>
>
>
> On Tue, Sep 29, 2020 at 8:34 AM, Paulo Motta <pa...@gmail.com>
> wrote:
>
> > 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 question but I believe it warrants a separate discussion
> > as part of a larger discussion on improving our development/quality
> process
> > post-4.0.
> >
> > *** CASSANDRA-15234 – Standardise config and JVM parameters - It looks
> >
> > like we have dropped the ball on this.
> >
> > It's sad that we dropped the ball on this important change but now I
> think
> > it's too late to make these changes as it will bring entropy towards
> > stabilizing 4.0. In that sense I think we should postpone this to the
> next
> > major and prioritize it earlier in the next cycle.
> >
> > Do all remaining flakey and failing units and dtests have jira tickets
> >
> > entered for 4.0-beta? Has the same been done, at least with rough
> > grouping, for the upgrade tests? Are these tied to the testing epics in
> any
> > way?
> >
> > 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)
> >
> > Has any triage efforts happened here?
> >
> > Not that I know of but maybe Josh/Jordan/Jon (J^3) are planning on
> looking
> > at it. I can take a stab at triaging some of these tickets.
> >
> > Do triaged bugs in this list get moved to fix version "4.x" ?
> >
> > I think in the spirit of expediting 4.0RC release we should mark bugs
> with
> > low severity (ie. those with a simple workaround) to 4.0.1. Any bug with
> > medium-high severity should be marked as 4.0-rc to favor stability.
> >
> > Are we duplicating efforts in the testing epics when others have already
> >
> > identified and reported the bugs but we just haven't triage them?
> >
> > That's a good point. I think as part of the triaging effort we should
> link
> > the bugs to existing quality epics so we can keep track of them.
> >
> > Em ter., 29 de set. de 2020 às 06:11, Sam Tunnicliffe <sa...@beobal.com>
> > escreveu:
> >
> > On 29 Sep 2020, at 09:50, Mick Semb Wever <mc...@apache.org> 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 outstanding issues that are hampering visibility of
> >
> > 4.0
> >
> > progress:
> > a) Quality testing issues with no shepherd;
> > b) Quality testing issues with shepherd, but no recent activity (~2
> >
> > months
> >
> > or less);
> > c) Quality testing issues with no objective acceptance
> >
> > criteria/Definition
> >
> > of Done;
> >
> > These Quality testing epics are a great focal point. How will we ensure
> > this QA persists, so it's not a manual checklist every release?
> >
> > The following is what I can see outstanding for the 4.0 release, that is
> > not afaik attached to these epic tickets…
> >
> > ** Those issues that slipped alpha…
> > *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
> > compression in protocol v5-beta
> > *** CASSANDRA-15234 – Standardise config and JVM parameters
> > *** CASSANDRA-13701 – Lower default num_tokens (blocked by
> > 'CASSANDRA-16079 Improve dtest runtime' )
> > ** 95 jira tickets in 4.0-beta and 4.0-rc
> > ** 631 jira bug tickets with no assigned "fix version"
> > ** Remaining flakey unit and dtests
> > ** Hundreds of failing and flakey upgrade dtests
> > ** Reports from driver tests, and other external test systems
> > ** Reports and/or integration with Fallout and Harry
> >
> > In a bit more detail…
> >
> > *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
> > compression in protocol v5-beta
> >
> > This looks like it is in its final patch and review. Is that correct Sam?
> >
> > Yes it is. I hope to get review finished and post some further perf
> > numbers this week.
> >
> > *** CASSANDRA-15234 – Standardise config and JVM parameters
> >
> > It looks like we have dropped the ball on this.
> >
> > *** CASSANDRA-13701 – Lower default num_tokens, and CASSANDRA-16079
> >
> > Some effort is undergoing from Ekaterina, David, and myself. I've put
> > together a prototype for caching bootstrapped ccm clusters, but i'm not
> yet
> > sure I can get much savings over the current tests and only a minimal
> > saving off the 13701 patch. Berenguer brought up that 40% of the dtests
> are
> > single-node, their performance not changed by 13701, and probably better
> > off rewritten to in-jvm tests.
> >
> > ** 95 jira tickets in 4.0-beta and 4.0-rc
> > ** Remaining flakey unit and dtests
> > ** Hundreds of failing and flakey upgrade dtests
> >
> > Do all remaining flakey and failing units and dtests have jira tickets
> > entered for 4.0-beta?
> > Has the same been done, at least with rough grouping, for the upgrade
> >
> > tests?
> >
> > Are these tied to the testing epics in any way?
> >
> > ** 631 jira bug tickets with no assigned "fix version" (who knows how
> >
> > many
> >
> > of these are applicable to 4.0?)
> >
> > Has any triage efforts happened here?
> > Do triaged bugs in this list get moved to fix version "4.x" ? Are we
> > duplicating efforts in the testing epics when others have already
> > identified and reported the bugs but we just haven't triage them?
> >
> > --------------------------------------------------------------------- To
> > unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org For additional
> > commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Josh McKenzie <jm...@apache.org>.
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 have a slight bias towards an independent epic for 4.0
test *fixing* instead of mixing the "new ways to test" with "cleaning up
the testing ways we know".
---
Josh McKenzie
On Tue, Sep 29, 2020 at 8:34 AM, Paulo Motta <pa...@gmail.com>
wrote:
> 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 question but I believe it warrants a separate discussion
> as part of a larger discussion on improving our development/quality process
> post-4.0.
>
> *** CASSANDRA-15234 – Standardise config and JVM parameters - It looks
>
> like we have dropped the ball on this.
>
> It's sad that we dropped the ball on this important change but now I think
> it's too late to make these changes as it will bring entropy towards
> stabilizing 4.0. In that sense I think we should postpone this to the next
> major and prioritize it earlier in the next cycle.
>
> Do all remaining flakey and failing units and dtests have jira tickets
>
> entered for 4.0-beta? Has the same been done, at least with rough
> grouping, for the upgrade tests? Are these tied to the testing epics in any
> way?
>
> 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)
>
> Has any triage efforts happened here?
>
> Not that I know of but maybe Josh/Jordan/Jon (J^3) are planning on looking
> at it. I can take a stab at triaging some of these tickets.
>
> Do triaged bugs in this list get moved to fix version "4.x" ?
>
> I think in the spirit of expediting 4.0RC release we should mark bugs with
> low severity (ie. those with a simple workaround) to 4.0.1. Any bug with
> medium-high severity should be marked as 4.0-rc to favor stability.
>
> Are we duplicating efforts in the testing epics when others have already
>
> identified and reported the bugs but we just haven't triage them?
>
> That's a good point. I think as part of the triaging effort we should link
> the bugs to existing quality epics so we can keep track of them.
>
> Em ter., 29 de set. de 2020 às 06:11, Sam Tunnicliffe <sa...@beobal.com>
> escreveu:
>
> On 29 Sep 2020, at 09:50, Mick Semb Wever <mc...@apache.org> 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 outstanding issues that are hampering visibility of
>
> 4.0
>
> progress:
> a) Quality testing issues with no shepherd;
> b) Quality testing issues with shepherd, but no recent activity (~2
>
> months
>
> or less);
> c) Quality testing issues with no objective acceptance
>
> criteria/Definition
>
> of Done;
>
> These Quality testing epics are a great focal point. How will we ensure
> this QA persists, so it's not a manual checklist every release?
>
> The following is what I can see outstanding for the 4.0 release, that is
> not afaik attached to these epic tickets…
>
> ** Those issues that slipped alpha…
> *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
> compression in protocol v5-beta
> *** CASSANDRA-15234 – Standardise config and JVM parameters
> *** CASSANDRA-13701 – Lower default num_tokens (blocked by
> 'CASSANDRA-16079 Improve dtest runtime' )
> ** 95 jira tickets in 4.0-beta and 4.0-rc
> ** 631 jira bug tickets with no assigned "fix version"
> ** Remaining flakey unit and dtests
> ** Hundreds of failing and flakey upgrade dtests
> ** Reports from driver tests, and other external test systems
> ** Reports and/or integration with Fallout and Harry
>
> In a bit more detail…
>
> *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
> compression in protocol v5-beta
>
> This looks like it is in its final patch and review. Is that correct Sam?
>
> Yes it is. I hope to get review finished and post some further perf
> numbers this week.
>
> *** CASSANDRA-15234 – Standardise config and JVM parameters
>
> It looks like we have dropped the ball on this.
>
> *** CASSANDRA-13701 – Lower default num_tokens, and CASSANDRA-16079
>
> Some effort is undergoing from Ekaterina, David, and myself. I've put
> together a prototype for caching bootstrapped ccm clusters, but i'm not yet
> sure I can get much savings over the current tests and only a minimal
> saving off the 13701 patch. Berenguer brought up that 40% of the dtests are
> single-node, their performance not changed by 13701, and probably better
> off rewritten to in-jvm tests.
>
> ** 95 jira tickets in 4.0-beta and 4.0-rc
> ** Remaining flakey unit and dtests
> ** Hundreds of failing and flakey upgrade dtests
>
> Do all remaining flakey and failing units and dtests have jira tickets
> entered for 4.0-beta?
> Has the same been done, at least with rough grouping, for the upgrade
>
> tests?
>
> Are these tied to the testing epics in any way?
>
> ** 631 jira bug tickets with no assigned "fix version" (who knows how
>
> many
>
> of these are applicable to 4.0?)
>
> Has any triage efforts happened here?
> Do triaged bugs in this list get moved to fix version "4.x" ? Are we
> duplicating efforts in the testing epics when others have already
> identified and reported the bugs but we just haven't triage them?
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org For additional
> commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Paulo Motta <pa...@gmail.com>.
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 question but I believe it warrants a separate discussion as
part of a larger discussion on improving our development/quality process
post-4.0.
> *** CASSANDRA-15234 – Standardise config and JVM parameters - It looks
like we have dropped the ball on this.
It's sad that we dropped the ball on this important change but now I think
it's too late to make these changes as it will bring entropy towards
stabilizing 4.0. In that sense I think we should postpone this to the next
major and prioritize it earlier in the next cycle.
> Do all remaining flakey and failing units and dtests have jira tickets
entered for 4.0-beta? Has the same been done, at least with rough grouping,
for the upgrade tests? Are these tied to the testing epics in any way?
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)
> Has any triage efforts happened here?
Not that I know of but maybe Josh/Jordan/Jon (J^3) are planning on looking
at it. I can take a stab at triaging some of these tickets.
> Do triaged bugs in this list get moved to fix version "4.x" ?
I think in the spirit of expediting 4.0RC release we should mark bugs with
low severity (ie. those with a simple workaround) to 4.0.1. Any bug with
medium-high severity should be marked as 4.0-rc to favor stability.
> Are we duplicating efforts in the testing epics when others have already
identified and reported the bugs but we just haven't triage them?
That's a good point. I think as part of the triaging effort we should link
the bugs to existing quality epics so we can keep track of them.
Em ter., 29 de set. de 2020 às 06:11, Sam Tunnicliffe <sa...@beobal.com>
escreveu:
>
>
> > On 29 Sep 2020, at 09:50, Mick Semb Wever <mc...@apache.org> 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 outstanding issues that are hampering visibility of
> 4.0
> >> progress:
> >> a) Quality testing issues with no shepherd;
> >> b) Quality testing issues with shepherd, but no recent activity (~2
> months
> >> or less);
> >> c) Quality testing issues with no objective acceptance
> criteria/Definition
> >> of Done;
> >
> >
> > These Quality testing epics are a great focal point. How will we ensure
> > this QA persists, so it's not a manual checklist every release?
> >
> > The following is what I can see outstanding for the 4.0 release, that is
> > not afaik attached to these epic tickets…
> >
> > ** Those issues that slipped alpha…
> > *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming
> > and compression in protocol v5-beta
> > *** CASSANDRA-15234 – Standardise config and JVM parameters
> > *** CASSANDRA-13701 – Lower default num_tokens (blocked by
> > 'CASSANDRA-16079 Improve dtest runtime' )
> > ** 95 jira tickets in 4.0-beta and 4.0-rc
> > ** 631 jira bug tickets with no assigned "fix version"
> > ** Remaining flakey unit and dtests
> > ** Hundreds of failing and flakey upgrade dtests
> > ** Reports from driver tests, and other external test systems
> > ** Reports and/or integration with Fallout and Harry
> >
> >
> > In a bit more detail…
> >
> >
> > *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
> > compression in protocol v5-beta
> >
> > This looks like it is in its final patch and review. Is that correct Sam?
> >
>
> Yes it is. I hope to get review finished and post some further perf
> numbers this week.
>
> >
> > *** CASSANDRA-15234 – Standardise config and JVM parameters
> >
> > It looks like we have dropped the ball on this.
> >
> >
> > *** CASSANDRA-13701 – Lower default num_tokens, and CASSANDRA-16079
> >
> > Some effort is undergoing from Ekaterina, David, and myself.
> > I've put together a prototype for caching bootstrapped ccm clusters, but
> > i'm not yet sure I can get much savings over the current tests and only a
> > minimal saving off the 13701 patch. Berenguer brought up that 40% of the
> > dtests are single-node, their performance not changed by 13701, and
> > probably better off rewritten to in-jvm tests.
> >
> >
> > ** 95 jira tickets in 4.0-beta and 4.0-rc
> > ** Remaining flakey unit and dtests
> > ** Hundreds of failing and flakey upgrade dtests
> >
> > Do all remaining flakey and failing units and dtests have jira tickets
> > entered for 4.0-beta?
> > Has the same been done, at least with rough grouping, for the upgrade
> tests?
> >
> > Are these tied to the testing epics in any way?
> >
> >
> > ** 631 jira bug tickets with no assigned "fix version" (who knows how
> many
> > of these are applicable to 4.0?)
> >
> > Has any triage efforts happened here?
> > Do triaged bugs in this list get moved to fix version "4.x" ?
> > Are we duplicating efforts in the testing epics when others have already
> > identified and reported the bugs but we just haven't triage them?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Sam Tunnicliffe <sa...@beobal.com>.
> On 29 Sep 2020, at 09:50, Mick Semb Wever <mc...@apache.org> 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 outstanding issues that are hampering visibility of 4.0
>> progress:
>> a) Quality testing issues with no shepherd;
>> b) Quality testing issues with shepherd, but no recent activity (~2 months
>> or less);
>> c) Quality testing issues with no objective acceptance criteria/Definition
>> of Done;
>
>
> These Quality testing epics are a great focal point. How will we ensure
> this QA persists, so it's not a manual checklist every release?
>
> The following is what I can see outstanding for the 4.0 release, that is
> not afaik attached to these epic tickets…
>
> ** Those issues that slipped alpha…
> *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming
> and compression in protocol v5-beta
> *** CASSANDRA-15234 – Standardise config and JVM parameters
> *** CASSANDRA-13701 – Lower default num_tokens (blocked by
> 'CASSANDRA-16079 Improve dtest runtime' )
> ** 95 jira tickets in 4.0-beta and 4.0-rc
> ** 631 jira bug tickets with no assigned "fix version"
> ** Remaining flakey unit and dtests
> ** Hundreds of failing and flakey upgrade dtests
> ** Reports from driver tests, and other external test systems
> ** Reports and/or integration with Fallout and Harry
>
>
> In a bit more detail…
>
>
> *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
> compression in protocol v5-beta
>
> This looks like it is in its final patch and review. Is that correct Sam?
>
Yes it is. I hope to get review finished and post some further perf numbers this week.
>
> *** CASSANDRA-15234 – Standardise config and JVM parameters
>
> It looks like we have dropped the ball on this.
>
>
> *** CASSANDRA-13701 – Lower default num_tokens, and CASSANDRA-16079
>
> Some effort is undergoing from Ekaterina, David, and myself.
> I've put together a prototype for caching bootstrapped ccm clusters, but
> i'm not yet sure I can get much savings over the current tests and only a
> minimal saving off the 13701 patch. Berenguer brought up that 40% of the
> dtests are single-node, their performance not changed by 13701, and
> probably better off rewritten to in-jvm tests.
>
>
> ** 95 jira tickets in 4.0-beta and 4.0-rc
> ** Remaining flakey unit and dtests
> ** Hundreds of failing and flakey upgrade dtests
>
> Do all remaining flakey and failing units and dtests have jira tickets
> entered for 4.0-beta?
> Has the same been done, at least with rough grouping, for the upgrade tests?
>
> Are these tied to the testing epics in any way?
>
>
> ** 631 jira bug tickets with no assigned "fix version" (who knows how many
> of these are applicable to 4.0?)
>
> Has any triage efforts happened here?
> Do triaged bugs in this list get moved to fix version "4.x" ?
> Are we duplicating efforts in the testing epics when others have already
> identified and reported the bugs but we just haven't triage them?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Mick Semb Wever <mc...@apache.org>.
> 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) Quality testing issues with no shepherd;
> b) Quality testing issues with shepherd, but no recent activity (~2 months
> or less);
> c) Quality testing issues with no objective acceptance criteria/Definition
> of Done;
These Quality testing epics are a great focal point. How will we ensure
this QA persists, so it's not a manual checklist every release?
The following is what I can see outstanding for the 4.0 release, that is
not afaik attached to these epic tickets…
** Those issues that slipped alpha…
*** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming
and compression in protocol v5-beta
*** CASSANDRA-15234 – Standardise config and JVM parameters
*** CASSANDRA-13701 – Lower default num_tokens (blocked by
'CASSANDRA-16079 Improve dtest runtime' )
** 95 jira tickets in 4.0-beta and 4.0-rc
** 631 jira bug tickets with no assigned "fix version"
** Remaining flakey unit and dtests
** Hundreds of failing and flakey upgrade dtests
** Reports from driver tests, and other external test systems
** Reports and/or integration with Fallout and Harry
In a bit more detail…
*** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
compression in protocol v5-beta
This looks like it is in its final patch and review. Is that correct Sam?
*** CASSANDRA-15234 – Standardise config and JVM parameters
It looks like we have dropped the ball on this.
*** CASSANDRA-13701 – Lower default num_tokens, and CASSANDRA-16079
Some effort is undergoing from Ekaterina, David, and myself.
I've put together a prototype for caching bootstrapped ccm clusters, but
i'm not yet sure I can get much savings over the current tests and only a
minimal saving off the 13701 patch. Berenguer brought up that 40% of the
dtests are single-node, their performance not changed by 13701, and
probably better off rewritten to in-jvm tests.
** 95 jira tickets in 4.0-beta and 4.0-rc
** Remaining flakey unit and dtests
** Hundreds of failing and flakey upgrade dtests
Do all remaining flakey and failing units and dtests have jira tickets
entered for 4.0-beta?
Has the same been done, at least with rough grouping, for the upgrade tests?
Are these tied to the testing epics in any way?
** 631 jira bug tickets with no assigned "fix version" (who knows how many
of these are applicable to 4.0?)
Has any triage efforts happened here?
Do triaged bugs in this list get moved to fix version "4.x" ?
Are we duplicating efforts in the testing epics when others have already
identified and reported the bugs but we just haven't triage them?
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Paulo Motta <pa...@gmail.com>.
Thanks for the detailed context Patrick! I see a lot of value on
videoconferences for presentations and brainstorms but I tend to prefer
mailing list as a medium for consensus-seeking discussions for the
following reasons:
- Asynchronous - gives folk time to think and digest (as mentioned by Ben
on the Kubernetes thread);
- Timezones - allows people from all timezones to participate;
- Inclusivity - accommodates more people in the discussion.
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) Quality testing issues with no shepherd;
b) Quality testing issues with shepherd, but no recent activity (~2 months
or less);
c) Quality testing issues with no objective acceptance criteria/Definition
of Done;
In order to facilitate the discussion I classified on this spreadsheet [1]
the quality epic (CASSANDRA-15536) subtickets into two categories: ON TRACK
/ NEEDS ATTENTION. An issue "Needs Attention" if it has one of the 3
problems mentioned above and is "On Track" otherwise.
## ON TRACK:
CASSANDRA-15583 4.0 quality testing: Tooling, Bundled and First Party
CASSANDRA-15584 4.0 quality testing: Tooling - External Ecosystem
CASSANDRA-15977 4.0 quality testing: Read Repair
## NEEDS ATTENTION:
CASSANDRA-14746 Ensure Netty Internode Messaging Refactor is Solid
CASSANDRA-15537 4.0 quality testing: Local Read/Write Path: Upgrade and
Diff Test
CASSANDRA-15538 4.0 quality testing: Local Read/Write Path: Other Areas
CASSANDRA-15579 "4.0 quality testing: Distributed Read/Write Path:
Coordination,
Replication, and Read Repair"
CASSANDRA-15580 4.0 quality testing: Repair
CASSANDRA-15581 4.0 quality testing: Compaction
CASSANDRA-15582 4.0 quality testing: metrics
CASSANDRA-15585 4.0 quality testing: Test Frameworks, Tooling, Infra /
Automation
CASSANDRA-15586 4.0 quality testing: Cluster Setup and Maintenance
CASSANDRA-15587 4.0 quality testing: Platforms and Runtimes
CASSANDRA-15588 4.0 quality testing: Cluster Upgrade
CASSANDRA-15921 4.0 quality testing: Materialized View
So in order to address these I think we should:
a) Seek volunteers to shepherd unassigned items;
b) Update status of inactive tickets;
c) Define objective acceptance criteria for each quality issue;
I believe we should do A) by actively seeking via mailing list volunteers
for each unassigned quality issue, while B) and C) should be coordinated
independently by the shepherd of each issue.
In my view this should improve accountability and transparency into 4.0 GA
progress. I would love to hear the community's thoughts on this.
[1]:
https://docs.google.com/spreadsheets/d/1E70HIo63KXP4ggLUCRYfuLLh_oJZNLuyuPdkiT6dMVE
Em sex., 25 de set. de 2020 às 14:08, Patrick McFadin <pm...@gmail.com>
escreveu:
> Hi Paulo,
>
> I appreciate you bringing this up because I'm sure that means plenty are
> thinking the same thing. Let me give you a little context and history.
>
> Last ApacheCon I proposed setting up a periodic zoom call to emulate some
> of the high bandwidth discussions that happen in-person. There was a good
> deal of discussion about how to do this appropriately, specifically by not
> creating isolated pockets of decision making. By providing yet another
> interaction method, increase participation in the project. I have seen
> these types of meetings work well in other OSS projects I'm involved with
> but it needs to be right for ASF guidelines.
>
> - No final decisions are made during the call. Any proposals go to the
> mailing list
> - Make a recording and post so nothing is exclusive
> - Post the chat transcripts (This is where the introverts interact and
> it can be quite lively)
>
> I consider our Zoom call as part of a package of how we interact.
> Jira - Code/feature specific discussion
> Mailing List - Official record of discussions and decisions
> Slack - Fast discussions with searchable text
> Video Call - High bandwidth discussions and presentations. Transactional in
> nature with an agenda.
>
> Having 25 people on a call to make a decision is not the intent or even
> reasonable. No matter what the setting is, even on email we don't get that
> many people weighing in on a topic.
>
> Using this meeting I posted as an example, the agenda is a discussion
> focused on the three unassigned Jiras. I expect we will have a few people
> that can directly speak about them and everyone else is a spectator or
> commenting in chat. The intent is to drive some activity on Jira.
>
> The timezone thing bothers me more than anything. I can't figure out how to
> make it completely equitable. The proposal as we formed the contributor
> meetings was to rotate the time to accommodate European timezones to
> Australia. The Kubernetes SIG had tried the 2 meetings in different halves
> of the world. Eventually consistent discussions don't work well.
>
> I don't want to go all Mandelorian and say "This is the way" so hopefully
> with this background we can continue the conversation. I always have
> considered this meeting to be a work in progress.
>
> Patrick
>
>
> On Fri, Sep 25, 2020 at 7:40 AM Paulo Motta <pa...@gmail.com>
> wrote:
>
> > Thanks for the initiative, Patrick!
> >
> > I wonder if videochat is the most inclusive method of discussion, not
> only
> > due to time zone differences, as mentioned by Alex, but also because it
> > makes it harder for introverts from voicing their opinions. In my
> > experience video calls with more than 5 participants tend to be dominated
> > by extroverts. Do we lose anything by making this discussion via email?
> >
> > Erick, I don't think you're an outsider at all, you're a very active
> member
> > of the community. I don't think it's healthy for the project to have this
> > mentality of "inner circle of contributors" - as long as you want to
> > contribute - either by participating in the discussions, answering
> mailing
> > list questions, contributing documentation or code - you're an equally
> > valuable member of the community.
> >
> > Em sex., 25 de set. de 2020 às 06:14, Erick Ramirez <
> > erick.ramirez@datastax.com> escreveu:
> >
> > > Very well said, Patrick!
> > >
> > > I'm not part of the inner circle of contributors so I'm a bit of an
> > > outsider. But as an advocate for Cassandra and the community, I'm
> > > optimistic that we will collectively get past this bump on the road,
> get
> > > 4.0 GA in 2020 and do bigger things in 2021. Cheers!
> > >
> >
>
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Patrick McFadin <pm...@gmail.com>.
Hi Paulo,
I appreciate you bringing this up because I'm sure that means plenty are
thinking the same thing. Let me give you a little context and history.
Last ApacheCon I proposed setting up a periodic zoom call to emulate some
of the high bandwidth discussions that happen in-person. There was a good
deal of discussion about how to do this appropriately, specifically by not
creating isolated pockets of decision making. By providing yet another
interaction method, increase participation in the project. I have seen
these types of meetings work well in other OSS projects I'm involved with
but it needs to be right for ASF guidelines.
- No final decisions are made during the call. Any proposals go to the
mailing list
- Make a recording and post so nothing is exclusive
- Post the chat transcripts (This is where the introverts interact and
it can be quite lively)
I consider our Zoom call as part of a package of how we interact.
Jira - Code/feature specific discussion
Mailing List - Official record of discussions and decisions
Slack - Fast discussions with searchable text
Video Call - High bandwidth discussions and presentations. Transactional in
nature with an agenda.
Having 25 people on a call to make a decision is not the intent or even
reasonable. No matter what the setting is, even on email we don't get that
many people weighing in on a topic.
Using this meeting I posted as an example, the agenda is a discussion
focused on the three unassigned Jiras. I expect we will have a few people
that can directly speak about them and everyone else is a spectator or
commenting in chat. The intent is to drive some activity on Jira.
The timezone thing bothers me more than anything. I can't figure out how to
make it completely equitable. The proposal as we formed the contributor
meetings was to rotate the time to accommodate European timezones to
Australia. The Kubernetes SIG had tried the 2 meetings in different halves
of the world. Eventually consistent discussions don't work well.
I don't want to go all Mandelorian and say "This is the way" so hopefully
with this background we can continue the conversation. I always have
considered this meeting to be a work in progress.
Patrick
On Fri, Sep 25, 2020 at 7:40 AM Paulo Motta <pa...@gmail.com>
wrote:
> Thanks for the initiative, Patrick!
>
> I wonder if videochat is the most inclusive method of discussion, not only
> due to time zone differences, as mentioned by Alex, but also because it
> makes it harder for introverts from voicing their opinions. In my
> experience video calls with more than 5 participants tend to be dominated
> by extroverts. Do we lose anything by making this discussion via email?
>
> Erick, I don't think you're an outsider at all, you're a very active member
> of the community. I don't think it's healthy for the project to have this
> mentality of "inner circle of contributors" - as long as you want to
> contribute - either by participating in the discussions, answering mailing
> list questions, contributing documentation or code - you're an equally
> valuable member of the community.
>
> Em sex., 25 de set. de 2020 às 06:14, Erick Ramirez <
> erick.ramirez@datastax.com> escreveu:
>
> > Very well said, Patrick!
> >
> > I'm not part of the inner circle of contributors so I'm a bit of an
> > outsider. But as an advocate for Cassandra and the community, I'm
> > optimistic that we will collectively get past this bump on the road, get
> > 4.0 GA in 2020 and do bigger things in 2021. Cheers!
> >
>
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Paulo Motta <pa...@gmail.com>.
Thanks for the initiative, Patrick!
I wonder if videochat is the most inclusive method of discussion, not only
due to time zone differences, as mentioned by Alex, but also because it
makes it harder for introverts from voicing their opinions. In my
experience video calls with more than 5 participants tend to be dominated
by extroverts. Do we lose anything by making this discussion via email?
Erick, I don't think you're an outsider at all, you're a very active member
of the community. I don't think it's healthy for the project to have this
mentality of "inner circle of contributors" - as long as you want to
contribute - either by participating in the discussions, answering mailing
list questions, contributing documentation or code - you're an equally
valuable member of the community.
Em sex., 25 de set. de 2020 às 06:14, Erick Ramirez <
erick.ramirez@datastax.com> escreveu:
> Very well said, Patrick!
>
> I'm not part of the inner circle of contributors so I'm a bit of an
> outsider. But as an advocate for Cassandra and the community, I'm
> optimistic that we will collectively get past this bump on the road, get
> 4.0 GA in 2020 and do bigger things in 2021. Cheers!
>
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Posted by Erick Ramirez <er...@datastax.com>.
Very well said, Patrick!
I'm not part of the inner circle of contributors so I'm a bit of an
outsider. But as an advocate for Cassandra and the community, I'm
optimistic that we will collectively get past this bump on the road, get
4.0 GA in 2020 and do bigger things in 2021. Cheers!