Cassandra 4.0 Dev Work Status

2020-01-14 Thread Joshua McKenzie
Hello and welcome to our kickoff email about the 4.0 release work status.
Structure and contents are fluid; if you'd like to see, or not see,
something, please reply and let me know as my goal is purely to help meet
the needs of our dev community here. My initial thinking is to send this
out weekly or biweekly depending on the volume of change; if things are
relatively unchanged by this time next week, I may go twice a month.

I put together a board
 of
recent or open 4.0 scope (anything closed within past 4 weeks should show
up). My intent is to use this purely as a visualization tool and not
advocate for any constraining work in progress, time in col tracking, or
other kanban-esque things. I find it useful to have a single place to poke
and prod at the state of a release and see where things might need some
attention.

Some observations that stand out (I'll drop ticket details at bottom of
email for convenience):

   - *Progress: *We've closed out 18 issues
   

   in the past 4 weeks of a total of 115 tickets
    across
   4.0-alpha, 4.0-beta, and 4.0.
   - *LHF: *We have 5 failing tests
   

on
   our Alpha Release with no assignee on them (*good Low Hanging Fruit for
   anyone that wants to get involved in the project*)
   - *Needs Review:* We have 3 beta tickets and 7 release tickets
   

that
   are Patch Available but do not have a reviewer
   - *Available to Work:* There are 6 alpha tickets, 5 beta tickets, and 14
   RC tickets
   

that
   do not have an assignee at this time. I'm excluding patch available or in
   review w/out assignee w/the assumption that they're in flight so probably
   just need to have assignee fixed on them (I'll take a look in a bit)
   - *Testing: *On our 4.0 Quality and test plan wiki article
   
,
   we have the following open opportunities
   

(all
   data as per wiki, will follow up w/Scott to confirm accuracy):
   - 13 of 17 areas for testing are not yet started
  - 8 of 17 areas do not yet have a Shepherd
  - 13 of the 17 areas do not yet have JIRA tickets associated with them

I'd personally like to see the information from the wiki translated into a
JIRA epic w/tickets for each area of testing and validation so we can track
status in one place and avoid information atrophy and staleness; given the
volume of information already in this current email, I'll defer that
discussion to another thread.

And lastly, I am intentionally avoiding any conversations about scope of
tickets for release in this email (4.0 vs. 4.x, etc). Given the friction
last week on the topic, I'd like to start out just by providing insight and
visibility to people and, assuming there's interest, I'm happy to
facilitate discussions around scope separately (on JIRA or dev list, etc).

*Below is an embedded list of tickets with states in case you want to more
easily peruse them or pick up work from here w/out going to the board
above:*
4.0 Test Failures with no Assignee

Link 
CASSANDRA-15307 Fix
flakey test_remote_query - cql_test.TestCQLSlowQuery test 4.0-alpha
Link 
CASSANDRA-15306 Investigate
why we are allocating 8MiB chunks and reaching the maximum BufferPool size
4.0-beta
Link 
CASSANDRA-15311 Fix
flakey test_13595 - consistency_test.TestConsistency 4.0-alpha
Link 
CASSANDRA-15315 Fix
failing test - test_rolling_upgrade_with_internode_ssl -
upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD
4.0-alpha
Link 
CASSANDRA-15314 Fix
failing test - test_rolling_upgrade_with_internode_ssl -
upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
4.0-alpha
Link 
CASSANDRA-15313 Fix
flaky - ChecksummingTransformerTest -
org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTes

Re: Cassandra 4.0 Dev Work Status

2020-01-14 Thread Joshua McKenzie
Apparently the formatting on this got straight borked. I may try sending
subsequent emails from my personal gmail instead of my @apache address to
see if that keeps the rich-text formatting. Sorry for the ugliness. ;)

On Tue, Jan 14, 2020 at 10:27 AM Joshua McKenzie 
wrote:

> Hello and welcome to our kickoff email about the 4.0 release work status.
> Structure and contents are fluid; if you'd like to see, or not see,
> something, please reply and let me know as my goal is purely to help meet
> the needs of our dev community here. My initial thinking is to send this
> out weekly or biweekly depending on the volume of change; if things are
> relatively unchanged by this time next week, I may go twice a month.
>
> I put together a board
>  of
> recent or open 4.0 scope (anything closed within past 4 weeks should show
> up). My intent is to use this purely as a visualization tool and not
> advocate for any constraining work in progress, time in col tracking, or
> other kanban-esque things. I find it useful to have a single place to poke
> and prod at the state of a release and see where things might need some
> attention.
>
> Some observations that stand out (I'll drop ticket details at bottom of
> email for convenience):
>
>- *Progress: *We've closed out 18 issues
>
> 
>in the past 4 weeks of a total of 115 tickets
> across
>4.0-alpha, 4.0-beta, and 4.0.
>- *LHF: *We have 5 failing tests
>
> 
>  on
>our Alpha Release with no assignee on them (*good Low Hanging Fruit
>for anyone that wants to get involved in the project*)
>- *Needs Review:* We have 3 beta tickets and 7 release tickets
>
> 
>  that
>are Patch Available but do not have a reviewer
>- *Available to Work:* There are 6 alpha tickets, 5 beta tickets, and
>14 RC tickets
>
> 
>  that
>do not have an assignee at this time. I'm excluding patch available or in
>review w/out assignee w/the assumption that they're in flight so probably
>just need to have assignee fixed on them (I'll take a look in a bit)
>- *Testing: *On our 4.0 Quality and test plan wiki article
>
> ,
>we have the following open opportunities
>
> 
>  (all
>data as per wiki, will follow up w/Scott to confirm accuracy):
>- 13 of 17 areas for testing are not yet started
>   - 8 of 17 areas do not yet have a Shepherd
>   - 13 of the 17 areas do not yet have JIRA tickets associated with
>   them
>
> I'd personally like to see the information from the wiki translated into a
> JIRA epic w/tickets for each area of testing and validation so we can track
> status in one place and avoid information atrophy and staleness; given the
> volume of information already in this current email, I'll defer that
> discussion to another thread.
>
> And lastly, I am intentionally avoiding any conversations about scope of
> tickets for release in this email (4.0 vs. 4.x, etc). Given the friction
> last week on the topic, I'd like to start out just by providing insight and
> visibility to people and, assuming there's interest, I'm happy to
> facilitate discussions around scope separately (on JIRA or dev list, etc).
>
> *Below is an embedded list of tickets with states in case you want to more
> easily peruse them or pick up work from here w/out going to the board
> above:*
> 4.0 Test Failures with no Assignee
> 
> Link 
> CASSANDRA-15307 Fix flakey test_remote_query - cql_test.TestCQLSlowQuery
> test 4.0-alpha
> Link 
> CASSANDRA-15306 Investigate why we are allocating 8MiB chunks and
> reaching the maximum BufferPool size 4.0-beta
> Link 
> CASSANDRA-15311 Fix flakey test_13595 - consistency_test.TestConsistency
> 4.0-alpha
> Link 
> CASSANDRA-15315 Fix failing test -
> test_rolling_upgrade_with_internode_ssl -
> upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsA

Re: Cassandra 4.0 Dev Work Status

2020-01-14 Thread Mick Semb Wever



>- *Progress: *We've closed out 18 issues
>
> 
>in the past 4 weeks of a total of 115 tickets
> across
>4.0-alpha, 4.0-beta, and 4.0.
>


 shouldn't we only have issues closed in 4.0-alpha, given we are not yet at 
4.0-beta and 4.0 ?

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



Re: Cassandra 4.0 Dev Work Status

2020-01-14 Thread Scott Andreas
I think the intent of the milestones is meant to indicate that contributors 
view completion of those items as exit criteria for alpha / beta / RC; not 
necessarily that all items will be completed in strict order.

In principle I'd interpret work targeting earlier milestones as higher 
priority, but am generally glad to see any contribution that helps us close 
items in any pre-release milestone. :-)


From: Mick Semb Wever 
Sent: Tuesday, January 14, 2020 10:27 AM
To: dev@cassandra.apache.org
Subject: Re: Cassandra 4.0 Dev Work Status



>- *Progress: *We've closed out 18 issues
>
> 
>in the past 4 weeks of a total of 115 tickets
> across
>4.0-alpha, 4.0-beta, and 4.0.
>


 shouldn't we only have issues closed in 4.0-alpha, given we are not yet at 
4.0-beta and 4.0 ?

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


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



Re: Cassandra 4.0 Dev Work Status

2020-01-14 Thread Mick Semb Wever


> I think the intent of the milestones is meant to indicate that 
> contributors view completion of those items as exit criteria for alpha 
> / beta / RC; not necessarily that all items will be completed in strict 
> order.


Yeah, though there's a nuance here between the ticket milestone when it is open 
and the version it becomes available in.

That is milestones are indicated by the fixVersions field while a ticket is 
open, and with the ".x" suffixed versions.

And when the ticket gets resolved/closed the fixVersion is then updated to the 
exact version it becomes available in. 

But given that we don't actually have those exact alpha1, alpha2, etc versions, 
maybe i missed a piece of info along the way, and this isn't true for the 
alpha/beta/RCs ?

 

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



Re: Cassandra 4.0 Dev Work Status

2020-01-14 Thread Scott Andreas
Just realized I'd misunderstood Mick's original email, apologies.

I'd originally interpreted it as a question of prioritization, but the intent 
was to ensure that the Fix Version field reflects the release a given change is 
/included in/, not /originally targeted for/. Apologies for my misunderstanding.

Agreed yes; it'd make sense to update recently-committed items that have a 
future fix version to indicate they were resolved during alpha. I haven't seen 
fix version refer to specific alpha releases (given that there's just one at 
the moment), but agree that it would be useful to differentiate between which 
alpha/beta/RC build a given change lands in.

Thanks Mick!

– Scott


From: Mick Semb Wever 
Sent: Tuesday, January 14, 2020 12:44 PM
To: dev@cassandra.apache.org
Subject: Re: Cassandra 4.0 Dev Work Status


> I think the intent of the milestones is meant to indicate that
> contributors view completion of those items as exit criteria for alpha
> / beta / RC; not necessarily that all items will be completed in strict
> order.


Yeah, though there's a nuance here between the ticket milestone when it is open 
and the version it becomes available in.

That is milestones are indicated by the fixVersions field while a ticket is 
open, and with the ".x" suffixed versions.

And when the ticket gets resolved/closed the fixVersion is then updated to the 
exact version it becomes available in.

But given that we don't actually have those exact alpha1, alpha2, etc versions, 
maybe i missed a piece of info along the way, and this isn't true for the 
alpha/beta/RCs ?



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


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