On Apr 10, 2018, at 5:24 PM, Josh McKenzie <jmcken...@apache.org> wrote:
>> 50'ish days is too short to draw a line in the sand,
>> especially as people balance work obligations with Cassandra feature
> What's a reasonable alternative / compromise for this? And what
> non-disruptive-but-still-large patches are in flight that we would want to
> delay the line in the sand for?
I don’t care about non disruptive patches to be really honest. Nobody’s running
trunk now, so it doesn’t matter to me if the patch landed 6 months ago or Jun
29, unless you can show me one person who’s ran a nontrivial multi-dc test
cluster under real load that included correctness validation. Short of that,
it’s untested, and the duration a patch has been in an untested repo is
If there’s really someone already testing trunk in a meaningful way (real
workloads, and verifying correctness), and that person is really able to find
and fix bugs, then tell me who it is and I’ll change my opinion (and I’m not
even talking about thousand node clusters, just someone who’s actually using
real data, like something upgraded from 2.1/3.0, and is checking to prove it
Otherwise, when the time comes for real users to plan real upgrades to a
hypothetical 4.1, they’ll have to do two sets of real, expensive, annoying
testing - one for the stuff in 4.0 (chunk cache, file format changes, internode
changes, etc), and a second for 4.0-4.1 changes for the invasive stuff I care
about and you don’t want to wait for.
I’d rather see us get all this stuff in and then spend real time testing and
fixing in a 4-6 month alpha/beta phase (where real users can help, because its
one real dedicated validation phase) than push this into two (probably
inadequately tested) releases.
But that’s just my opinion, and I’ll support it with my one vote, and I may get
outvoted, but that’s what I’d rather see happen.
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org