Hi Everyone, Josh is traveling this week so he sent me a brief summary and I offered to send it to the mailing list w/ a few updates. There was enough progress in the last week to warrant an update.
The 4.0 board can be found at https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355. More details below. - *Progress*: We closed 8 more tickets this week for a rolling total of 26 (up from 18 in the last update) of 122 (up from 115 last week) across 4.0-alpha, 4.0-beta, and 4.0. Closed: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixversion%20in%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-beta)%20AND%20resolved%20%3E%3D%20-4w <https://issues.apache.org/jira/issues/?jql=project%20=%20CASSANDRA%20AND%20fixversion%20in%20(4.0,%204.0.0,%204.0-alpha,%204.0-beta)%20AND%20resolved%20%3E=%20-4w> Total: https://issues.apache.org/jira/issues/?filter=12347782 *LHF / Failing Tests*: 3 of the 6 failing tests now have an assignee. The remaining 3 unassigned tickets can be found at https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1660&quickFilter=1658 *Needs Reviewer*: 6 tickets need a reviewer. This is down from 10 last week. They can be found at https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1659 *Available to work*: 3 alpha (the remaining test failures), 4 beta, and 18 RC issues are unassigned. They can be found at https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&view=detail&selectedIssue=CASSANDRA-15308&quickFilter=1661&quickFilter=1658 *Ready to Commit*: 7 tickets are marked ready to commit. They can be found at https://issues.apache.org/jira/browse/CASSANDRA-15461?jql=project%20%3D%20CASSANDRA%20AND%20fixversion%20in%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-beta)%20AND%20status%20%3D%20%22Ready%20to%20Commit%22%20 <https://issues.apache.org/jira/browse/CASSANDRA-15461?jql=project%20=%20CASSANDRA%20AND%20fixversion%20in%20(4.0,%204.0.0,%204.0-alpha,%204.0-beta)%20AND%20status%20=%20%22Ready%20to%20Commit%22> *Testing*: On our 4.0 Quality and Test Plan Wiki ( https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans <https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality:+Components+and+Test+Plans>) we have 5 remaining open Shepherd positions (down from 7 last week). 11 areas do not have a tracking ticket (down from 13 last week). 13 areas remain not started. Thanks everyone for your contributions! Its exciting to see this progress. Jordan On Wed, Jan 15, 2020 at 5:37 AM Benedict Elliott Smith <bened...@apache.org> wrote: > Specifically, if anyone's interested, I think we should probably maintain > three tags for work landing in 4.0, e.g. 4.0-alpha1, 4.0-alpha, 4.0 > > This helps track all of the relevant information, the first limited > release, the first general release, and the point in the release process it > was delivered. > > On 15/01/2020, 13:34, "Benedict Elliott Smith" <bened...@apache.org> > wrote: > > I think there's always been a distinction in the way we treat > alphas/betas versus patch releases, because they have a staged delivery > (landing for dev and users in different releases). I don't know we've ever > been totally consistent about it across major versions though. > > I think we can view 4.0-alpha as equivalent to 4.x, except that it has > value being maintained after commit, to historically track where things > land in the release process. It was discussed somewhere, not ages ago and > I can't remember where, that there was value in this. There's probably > also value in introducing 4.0-alpha1 etc on top. > > We should probably decide and document it, as you say, so that we can > at least be consistent next major. > > > On 15/01/2020, 13:18, "Joshua McKenzie" <jmcken...@apache.org> wrote: > > Historically I believe we used the ".x" nomenclature to indicate > general > release we wanted things in (4.x, 3.11.x, 3.6.x, etc), and then > upon merge > update the FixVersion to reflect which release it actually went > in. Is that > still a thing, and whether a thing or not, is the current > appropriate usage > of FixVersion on the project documented somewhere? > > On Wed, Jan 15, 2020 at 2:24 AM Scott Andreas < > sc...@paradoxica.net> wrote: > > > 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 <m...@apache.org> > > 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 > > > > > > > > > --------------------------------------------------------------------- > 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 > On Tue, Jan 14, 2020 at 7:27 AM Joshua McKenzie <jmcken...@apache.org> 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 > <https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355> 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 > < > https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixversion%20in%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-beta)%20AND%20resolved%20%3E%3D%20-4w > > > in the past 4 weeks of a total of 115 tickets > <https://issues.apache.org/jira/issues/?filter=12347782> across > 4.0-alpha, 4.0-beta, and 4.0. > - *LHF: *We have 5 failing tests > < > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&selectedIssue=CASSANDRA-15314&quickFilter=1660&quickFilter=1658 > > > 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 > < > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1659 > > > 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 > < > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&selectedIssue=CASSANDRA-15314&quickFilter=1661&quickFilter=1658 > > > 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 > < > https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans > >, > we have the following open opportunities > < > https://docs.google.com/spreadsheets/d/1gP1MsC1ZZ3M0Rf8tIDJ30hI2DqYcLsVLSPgPXwSb6is/edit#gid=0 > > > (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 > <https://issues.apache.org/jira/issues/?filter=12347786> > Link <https://issues.apache.org/jira/browse/CASSANDRA-15307> > CASSANDRA-15307 Fix > flakey test_remote_query - cql_test.TestCQLSlowQuery test 4.0-alpha > Link <https://issues.apache.org/jira/browse/CASSANDRA-15306> > CASSANDRA-15306 Investigate > why we are allocating 8MiB chunks and reaching the maximum BufferPool size > 4.0-beta > Link <https://issues.apache.org/jira/browse/CASSANDRA-15311> > CASSANDRA-15311 Fix > flakey test_13595 - consistency_test.TestConsistency 4.0-alpha > Link <https://issues.apache.org/jira/browse/CASSANDRA-15315> > 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 <https://issues.apache.org/jira/browse/CASSANDRA-15314> > 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 <https://issues.apache.org/jira/browse/CASSANDRA-15313> > CASSANDRA-15313 Fix > flaky - ChecksummingTransformerTest - > org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest > 4.0-alpha > Link <https://issues.apache.org/jira/browse/CASSANDRA-15308> > CASSANDRA-15308 Fix > flakey testAcquireReleaseOutbound - org.apache.cassandra.net > .ConnectionTest > 4.0-alpha > > Patch Available Needing Reviewer(s) > < > https://issues.apache.org/jira/issues/?filter=12347784&jql=project%20%3D%20cassandra%20AND%20fixversion%20IN%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-beta)%20AND%20resolution%20%3D%20unresolved%20AND%20status%20!%3D%20resolved%20AND%20status%20%3D%20%22Patch%20Available%22%20AND%20reviewer%20is%20EMPTY%20AND%20reviewers%20is%20EMPTY%20ORDER%20BY%20priority%20DESC%2C%20assignee > > > Link <https://issues.apache.org/jira/browse/CASSANDRA-14740> > CASSANDRA-14740 BlockingReadRepair > does not maintain monotonicity during range movements > Link <https://issues.apache.org/jira/browse/CASSANDRA-15305> > CASSANDRA-15305 Fix > multi DC nodetool status output > Link <https://issues.apache.org/jira/browse/CASSANDRA-15462> > CASSANDRA-15462 Purgable > tombstones can cause false positives in repaired data tracking > Link <https://issues.apache.org/jira/browse/CASSANDRA-15461> > CASSANDRA-15461 Legacy > counter shards can cause false positives in repaired data tracking > Link <https://issues.apache.org/jira/browse/CASSANDRA-14842> > CASSANDRA-14842 SSL > connection problems when upgrading to 4.0 when upgrading from 3.0.x > Link <https://issues.apache.org/jira/browse/CASSANDRA-15300> > CASSANDRA-15300 4.0 > rpmbuild spec file is missing auditlogviewer and fqltool > Link <https://issues.apache.org/jira/browse/CASSANDRA-12995> > CASSANDRA-12995 update > hppc dependency to 0.7 > Link <https://issues.apache.org/jira/browse/CASSANDRA-15257> > CASSANDRA-15257 Remove > joda time from dependencies > Link <https://issues.apache.org/jira/browse/CASSANDRA-14904> > CASSANDRA-14904 SSTableloader > doesn't understand listening for CQL connections on multiple ports > Link <https://issues.apache.org/jira/browse/CASSANDRA-14788> > CASSANDRA-14788 Add > test coverage workflows to CircleCI config > > 4.0 with no assignee > <https://issues.apache.org/jira/issues/?filter=12347783> > Link <https://issues.apache.org/jira/browse/CASSANDRA-14608> > CASSANDRA-14608 Confirm > correctness of windows scripts post-9608 > Link <https://issues.apache.org/jira/browse/CASSANDRA-14520> > CASSANDRA-14520 ClosedChannelException > handled as FSError > Link <https://issues.apache.org/jira/browse/CASSANDRA-13254> > CASSANDRA-13254 move > compaction strategies to dedicated pages and expand on details > Link <https://issues.apache.org/jira/browse/CASSANDRA-15212> > CASSANDRA-15212 CassandraInputStream > Bugs > Link <https://issues.apache.org/jira/browse/CASSANDRA-15214> > CASSANDRA-15214 OOMs > caught and not rethrown > Link <https://issues.apache.org/jira/browse/CASSANDRA-15307> > CASSANDRA-15307 Fix > flakey test_remote_query - cql_test.TestCQLSlowQuery test > Link <https://issues.apache.org/jira/browse/CASSANDRA-15306> > CASSANDRA-15306 > Investigate why we are allocating 8MiB chunks and reaching the maximum > BufferPool size > Link <https://issues.apache.org/jira/browse/CASSANDRA-15311> > CASSANDRA-15311 Fix > flakey test_13595 - consistency_test.TestConsistency > Link <https://issues.apache.org/jira/browse/CASSANDRA-14517> > CASSANDRA-14517 Short > read protection can cause partial updates to be read > Link <https://issues.apache.org/jira/browse/CASSANDRA-15315> > CASSANDRA-15315 > Fix failing test - test_rolling_upgrade_with_internode_ssl - > > upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD > Link <https://issues.apache.org/jira/browse/CASSANDRA-15314> > CASSANDRA-15314 > Fix failing test - test_rolling_upgrade_with_internode_ssl - > > upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD > Link <https://issues.apache.org/jira/browse/CASSANDRA-15313> > CASSANDRA-15313 > Fix flaky - ChecksummingTransformerTest - > org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest > Link <https://issues.apache.org/jira/browse/CASSANDRA-14754> > CASSANDRA-14754 Add > verification of state machine in StreamSession > Link <https://issues.apache.org/jira/browse/CASSANDRA-14748> > CASSANDRA-14748 Recycler$WeakOrderQueue > occupies Heap > Link <https://issues.apache.org/jira/browse/CASSANDRA-14793> > CASSANDRA-14793 Improve > system table handling when losing a disk when using JBOD > Link <https://issues.apache.org/jira/browse/CASSANDRA-15308> > CASSANDRA-15308 Fix > flakey testAcquireReleaseOutbound - org.apache.cassandra.net > .ConnectionTest > Link <https://issues.apache.org/jira/browse/CASSANDRA-14801> > CASSANDRA-14801 calculatePendingRanges > no longer safe for multiple adjacent range movements > Link <https://issues.apache.org/jira/browse/CASSANDRA-15406> > CASSANDRA-15406 Add > command to show the progress of data streaming and index build > Link <https://issues.apache.org/jira/browse/CASSANDRA-15234> > CASSANDRA-15234 Standardise > config and JVM parameters > Link <https://issues.apache.org/jira/browse/CASSANDRA-14697> > CASSANDRA-14697 Transient > Replication 4.0 pre-release followup work > Link <https://issues.apache.org/jira/browse/CASSANDRA-14296> > CASSANDRA-14296 Fix > eclipse-warnings introduced by 7544 parameter handling > Link <https://issues.apache.org/jira/browse/CASSANDRA-15369> > CASSANDRA-15369 > Fake row deletions and range tombstones, causing digest mismatch and > sstable growth > Link <https://issues.apache.org/jira/browse/CASSANDRA-15229> > CASSANDRA-15229 BufferPool > Regression > Link <https://issues.apache.org/jira/browse/CASSANDRA-14606> > CASSANDRA-14606 Add > documentation for java 11 support > Thanks everyone for your contributions to this process and for your > attention! >
