Details
-
Task
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
None
-
Quality Assurance
-
Normal
-
All
-
None
-
Description
The python dtests (cassandra-dtest repo) creates its clusters using ccm.
The version of ccm it uses is the HEAD of the cassandra-test branch. This is referenced in the requirements.txt.
The history for why a separate branch of ccm is used by dtests is explained in https://github.com/apache/cassandra-dtest/pull/13
Long story short: the separate branch avoids two headaches
- the 'latest commit to master' broke all the c* builds surprises', and
- the 'i have to cut a release of ccm just to get a ccm change into use by dtests'
But the two branches: master and cassandra-test; have effectively been treated as two separate repositories, with (non-fast-forward) merges happening in both directions. This makes the git history of both branches messy and difficult to use, and it makes the merge strategy confusing. Bi-directional merging between branches is considered a poor practice by many (Laura Wingerd's 'The Flow of Change' presentation and book refers to this as "don't drive through hedges" and encourages the "merge down, copy up" approach against the "tofu scale: firm above, soft below").
To date, AFAIK no merges between the branches have occurred since January 2018.
A possible improvement to this process is to replace the cassandra-test branch with a floating tag (of the same name).
That way new commits to master are not automatically used by the python dtests. And changes made to ccm and intended/needed to be used by the dtests can be put in use by re-tagging cassandra-test to master's HEAD.
The re-tagging approach is
git tag -a -f cassandra-test git push origin :refs/tags/cassandra-test git push -f origin --tags
Attachments
Issue Links
- is related to
-
-
- Resolved
-