-- Jeff Jirsa
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 >> development. > > 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 entirely irrelevant. 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 matches expectations). 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
