Huh, I was writing my response for quite a while and getting distracted so didn't see this, but yeah if I had a vote, this would obviously have it.
On 11 April 2018 at 03:03, Jeff Jirsa <jji...@gmail.com> wrote: > > > -- > 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 > >
