> > I think committing 8099, or at the very least, parts of it, behind an > experimental flag would have been the right thing to do.
With a major refactor like that, it's a staggering amount of extra work to have a parallel re-write of core components of a storage engine accessible in parallel to the major based on an experimental flag in the same branch. I think the complexity in the code-base of having two such channels in parallel would be an altogether different kind of burden along with making the work take considerably longer. The argument of modularizing a change like that, however, is something I can get behind as a matter of general principle. As we discussed at NGCC, the amount of static state in the C* code-base makes this an aspirational goal rather than a reality all too often, unfortunately. Not looking to get into the discussion of the appropriateness of 8099 and other major refactors like it (nio MessagingService for instance) - but there's a difference between building out new features and shielding the code-base and users from their complexity and reliability and refactoring core components of the code-base to keep it relevant. On Sun, Oct 1, 2017 at 5:01 PM, Dave Brosius <dbros...@apache.org> wrote: > triggers > > > On 10/01/2017 11:25 AM, Jeff Jirsa wrote: > >> Historical examples are anything that you wouldn’t bet your job on for >> the first release: >> >> Udf/uda in 2.2 >> Incremental repair - would have yanked the flag following 9143 >> SASI - probably still experimental >> Counters - all sorts of correctness issues originally, no longer true >> since the rewrite in 2.1 >> Vnodes - or at least shuffle >> CDC - is the API going to change or is it good as-is? >> CQL - we’re on v3, what’s that say about v1? >> >> Basically anything where we can’t definitively say “this feature is going >> to work for you, build your product on it” because companies around the >> world are trying to make that determination on their own, and they don’t >> have the same insight that the active committers have. >> >> The transition out we could define as a fixed number of releases or a dev@ >> vote, I don’t think you’ll find something that applies to all experimental >> features, so being flexible is probably the best bet there >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
