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 <> wrote:

> --
> Jeff Jirsa
> On Apr 10, 2018, at 5:24 PM, Josh McKenzie <> 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:
> For additional commands, e-mail:

Reply via email to