20200609 Cassandra 4.0 Status Update

[Jon Meredith]

Hi Everyone,

[Board]
The board can be found here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355

[New Tickets]
In the last seven days we have opened three new alpha tickets, two of which
closed already and seven beta tickets, one closed, two in review.

Please remember to be thoughtful about what Fix Version you assign
a ticket to as we get closer to being able to release beta1.

https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

In good news, thirteen were closed. (nine alpha, three beta, one rc)

[Tickets That Need Attention]
In alpha, server_encryption_options and expose table schema have been
quiet for a while (see Alpha Status)

[Needs Reviewer]

2 tickets assigned to Beta are looking for reviewers:
 - https://issues.apache.org/jira/browse/CASSANDRA-15229 BufferPool Regression
 - https://issues.apache.org/jira/browse/CASSANDRA-13047 Point cqlsh
help to the new doc

[Alpha Status]

We are down to 7 tickets tagged against 4.0-alpha after the recent
triage... this might really be it.

Four of which are in review/cleanup.
 - (active today) CASSANDRA-15677 Topology events are not sent to
clients if the nodes use the same network interface
 - (active today) CASSANDRA-15234 Standardise config and JVM parameters
 - (last update 30th May) CASSANDRA-15262 server_encryption_options is
not backwards compatible with 3.11
 - (last update 6th May) CASSANDRA-14825 Expose table schema for drivers

Two API / Configuration / Protocol changes
 - CASSANDRA-15146 Transitional TLS server configuration options are
overly complex
   should close after C-15234 lands, rename server_encryption_options
to internode_encryption_options.
 - CASSANDRA-15299 follow-up: improve checksumming and compression in
protocol v5-beta

One flaky test issue / bug
 - CASSANDRA-15863 dtest failure TestReplaceAddress.test_restart_failed_replace


[Beta Status]
There are 32 issues not marked done that are assigned to Beta (down from 41
at the time of the last status update). These tickets are primarily
comprised of the testing epic work, known regressions, planned
improvements, and flaky tests.

[Cumulative Flow Diagram]
A visual measure of our progress can be found here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=reporting=cumulativeFlowDiagram=939=936=931=1505=1506=1514=1509=1512=1507=2020-04-07=2020-04-28

Thanks everyone!
Jon

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] governance on the Apache Cassandra project

[Joshua McKenzie]

I've tightened up some of the verbiage and also updated the doc to be
consistent w/the current CEP procedures on the wiki re: voting and
ratifying.

As always, more feedback is welcome.

On Mon, Jun 8, 2020 at 9:38 AM Joshua McKenzie  wrote:

>  One example is we require a CEP to have a Shepherd that is a PMC member
>
> This should be revised from "PMC member" to "committer"
>
>
> On Mon, Jun 8, 2020 at 6:12 AM Mick Semb Wever  wrote:
>
>> > > With regards to CEPs, I personally don't see any value in voting to
>> start
>> > one.
>> >
>> > Agree with this, and I'd go even further - requiring a vote in order to
>> > propose an idea runs so counter to the idea of a CEP that it would
>> default
>> > the purpose of even having them.  The CEP is the _proposal_ for a change
>> > that gets fleshed out enough so people can understand the idea and
>> _then_
>> > vote on it, not the other way around.
>>
>>
>> Totally agree that CEPs should be as light-weight as possible, and with
>> the
>> sentiments above. But would also like to keep the discussion open to
>> encourage and include as many voices as possible.
>>
>> My _questioning_ is around the value in "initial exposure and discussion".
>> It is implied already that there is lazy consensus in starting a CEP, and
>> that starting a CEP is more than just an initial proposal of an idea. One
>> example is we require a CEP to have a Shepherd that is a PMC member.
>> Encouraging a vote, or better-yet keeping it light-weight: an initial
>> DISCUSS thread as early as possible in the CEP lifecycle does come with
>> value. From openly calling out for a Shepherd, to allowing the more
>> experienced community members to add their insight (without having to get
>> formally involved in it), there's potential value in encouraging such
>> open-mode opening discussion early on (versus the cost of additional
>> process).
>>
>> Really interested in hearing from folk from other communities and projects
>> that do CEP/CIP and how their lifecycle through the process works and what
>> they have learnt.
>>
>