Github user ptnapoleon commented on the issue:
https://github.com/apache/cassandra-dtest/pull/13
So, I am -0.5 on this. We used to do this. The problem is that ccm has
other consumers than dtest, and worse, is both an app and a library. As a
result, sometimes changes go into ccm which break dtests, despite our best
efforts at testing ccm changes. When we switched to versioning ccm, and
manually pulling in ccm versions, it made development in both systems much
easier.
For the scope of this project, we obviously only care about difficulty in
developing on dtest. Anecdotally, people vastly preferred manual changes to the
ccm dependency, as that's much more bisectable when debugging failures. The
recent upgrade failures on C* trunk are due to a ccm change. When debugging
that, I was able to bisect it to precisely the commit that bumped the ccm
version, which let me easily find the ccm commit that caused the issue. Then I
released ccm 3.1.1 with the fix.
When we used to pull in ccm automatically, bisecting issues caused by ccm
didn't work, and one would have to tie in the time at which CI jobs ran to the
time at which ccm commits were made. It's much more unpleasant. I do know we
pull in the python driver from a branch. However, that branch isn't pushed to
with every new commit to the new driver. Rather, commits are made there in a
batch when a new, tested version of the driver is released, or very explicitly
go in tied with new C* features (think a cqlsh feature going in alongside a
driver feature). The people developing the drivers have far more resources to
guarantee the correctness of the driver than I have to do the same with ccm.
Now, I know that's a lot of negatives up-front, sorry about that. Possible
points in favor that I am aware of are:
1. People don't test dtest when bumping the ccm version anyway, so why
bother with the formality
2. We can increase the speed at which ccm fixes are used in dtest CI
3. It is too inconvenient to get committers to push changes to dtest deps.
I think (1) is throwing the baby out with the bathwater, and for (2), is a
handful of hours to run CI such a huge deal? It is not like the OSS C* project
relies on dtest fixes having a very fast SLA. (3) is definitely true.
On the ccm side, how would you want me, effectively the only maintainer
right now, to manage this branch? Either it gets every commit, in which case
let's just pull from master, or it gets batched updates which are equivalent to
releases. In the latter option, that's just pushing the burden of testing dtest
to me, rather than the dtest developers (yes that also includes me, I know).
It's also identical to just pulling in releases on the dtest side, except for
how those releases are pulled in. If you want a branch that selectively pulls
in commits just for dtest, that will diverge from master, my answer as the ccm
maintainer is no, I will not maintain a fork.
Again, just -0.5 on this. Frankly, I don't develop on dtest much, so if
this is easier for you and the other people who do, I totally okay with
supporting the branch on the ccm side if you let me know how you want that
branch maintained.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
