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