[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16383:
-------------------------------------------
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|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
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|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
and
[book|https://books.google.no/books?id=mlm61wb2v3MC&pg=PT191&lpg=PT191&dq=%22don%27t+drive+through+hedges%22&source=bl&ots=I_rYBRJwTD&sig=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng&hl=en&sa=X&ved=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage&q=%22don't%20drive%20through%20hedges%22&f=false]
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
{code}
git tag -a -f cassandra-test
git push origin :refs/tags/cassandra-test
git push origin tag cassandra-test
{code}
was:
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|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
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|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
and
[book|https://books.google.no/books?id=mlm61wb2v3MC&pg=PT191&lpg=PT191&dq=%22don%27t+drive+through+hedges%22&source=bl&ots=I_rYBRJwTD&sig=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng&hl=en&sa=X&ved=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage&q=%22don't%20drive%20through%20hedges%22&f=false]
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
{code}
git tag -a -f cassandra-test
git push origin :refs/tags/cassandra-test
git push origin --tags
{code}
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> -------------------------------------------------------------------
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Apache Cassandra
> Issue Type: Task
> Components: Test/dtest/python
> Reporter: Michael Semb Wever
> Assignee: Michael Semb Wever
> Priority: Normal
> Fix For: 2.2.20, 3.0.24, 3.11.10, 4.0-rc1, 4.0
>
>
> 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|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> 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|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC&pg=PT191&lpg=PT191&dq=%22don%27t+drive+through+hedges%22&source=bl&ots=I_rYBRJwTD&sig=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng&hl=en&sa=X&ved=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage&q=%22don't%20drive%20through%20hedges%22&f=false]
> 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
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push origin tag cassandra-test
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
