Reviewers should be able to suggest when experimental is warranted, and conversation on dev+jira to justify when it’s transitioned from experimental to stable?
We should remove the flag as soon as we’re (collectively) confident in a feature’s behavior - at least correctness, if not performance. > On Sep 29, 2017, at 10:31 PM, Marcus Eriksson <krum...@gmail.com> wrote: > > +1 on marking MVs experimental, but should there be some point in the > future where we consider removing them from the code base unless they have > gotten significant improvement as well? > > We probably need to enforce some kind of process for adding new > experimental features in the future - perhaps a mail like this one to dev@ > motivating why it should be experimental? > > /Marcus > > On Sat, Sep 30, 2017 at 1:15 AM, Vinay Chella <vche...@netflix.com.invalid> > wrote: > >> We tried perf testing MVs internally here but did not see good results with >> it, hence paused its usage. +1 on tagging certain features which are not >> PROD ready or not stable enough. >> >> Regards, >> Vinay Chella >> >>> On Fri, Sep 29, 2017 at 7:22 PM, Ben Bromhead <b...@instaclustr.com> wrote: >>> >>> I'm a fan of introducing experimental flags in general as well, +1 >>> >>> >>> >>>> On Fri, 29 Sep 2017 at 13:22 Jon Haddad <j...@jonhaddad.com> wrote: >>>> >>>> I’m very much +1 on this, and to new features in general. >>>> >>>> I think having a clear line in which we classify something as >> production >>>> ready would be nice. It would be great if committers were using the >>>> feature in prod and could vouch for it’s stability. >>>> >>>>> On Sep 29, 2017, at 1:09 PM, Blake Eggleston <beggles...@apple.com> >>>> wrote: >>>>> >>>>> Hi dev@, >>>>> >>>>> I’d like to propose that we retroactively classify materialized views >>> as >>>> an experimental feature, disable them by default, and require users to >>>> enable them through a config setting before using. >>>>> >>>>> Materialized views have several issues that make them (effectively) >>>> unusable in production. Some of the issues aren’t just implementation >>>> problems, but problems with the design that aren’t easily fixed. It’s >>>> unfair of us to make features available to users in this state without >>>> providing a clear warning that bad or unexpected things are likely to >>>> happen if they use it. >>>>> >>>>> Obviously, this isn’t great news for users that have already adopted >>>> MVs, and I don’t have a great answer for that. I think that’s sort of a >>>> sunk cost at this point. If they have any MV related problems, they’ll >>> have >>>> them whether they’re marked experimental or not. I would expect this to >>>> reduce the number of users adopting MVs in the future though, and if >> they >>>> do, it would be opt-in. >>>>> >>>>> Once MVs reach a point where they’re usable in production, we can >>> remove >>>> the flag. Specifics of how the experimental flag would work can be >>> hammered >>>> out in a forthcoming JIRA, but I’d imagine it would just prevent users >>> from >>>> creating new MVs, and maybe log warnings on startup for existing MVs if >>> the >>>> flag isn’t enabled. >>>>> >>>>> Let me know what you think. >>>>> >>>>> Thanks, >>>>> >>>>> Blake >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>> >>>> -- >>> Ben Bromhead >>> CTO | Instaclustr <https://www.instaclustr.com/> >>> +1 650 284 9692 >>> Reliability at Scale >>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
