>
> 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
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 iss
Thanks Jeff, I will check this out.
On 1 Oct 2017 20:31 +0300, Jeff Jirsa , wrote:
> Check out CCM - it’s how the project writes distributed tests
>
> https://github.com/pcmanus/ccm
>
> --
> Jeff Jirsa
>
>
> > On Oct 1, 2017, at 10:25 AM, m...@salih.xyz wrote:
> >
> > Hi there,
> > I am playing wi
Hello,
posted also to the users list, but possibly it is better targeted to this list,
cause 3.11.1 is close to be released?
We were facing a memory leak with 3.11.0
(https://issues.apache.org/jira/browse/CASSANDRA-13754) thus upgraded our
loadtest environment to a snapshot build of 3.11.1. Ha
Check out CCM - it’s how the project writes distributed tests
https://github.com/pcmanus/ccm
--
Jeff Jirsa
> On Oct 1, 2017, at 10:25 AM, m...@salih.xyz wrote:
>
> Hi there,
> I am playing with Gossip classes and looking for a way to create nodes and
> join to cluster while debugging in IDE
Hi there,
I am playing with Gossip classes and looking for a way to create nodes and join
to cluster while debugging in IDEA. Is there any way to make this process
simple? Or shoud I do something like Docker containers?
Thanks a lot!
Cheers
Salih
I think you're presenting a false dichotomy here. Yes there are people who are
not interested in taking risks with C* and are still running 1.2, there are
probably a few people who would put trunk in prod if we packaged it up for
them, but there's a whole spectrum of users in between. Operator c
So basically we're saying that even with a lot of tests, you're never sure
to cover all the possible edge cases and the real stamp for "production
readiness" is only when the "experimental features" have been deployed in
various clusters with various scenarios/use-cases, just re-phrasing Blake
here
I'm not sure the main issue in the case of MVs is testing. In this case it
seems to be that there are some design issues and/or the design was only works
in some overly restrictive use cases. That MVs were committed knowing these
were issues seems to be the real problem. So in the case of MVs, s
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
How should we transition one feature from the "experimental" state to
"production ready" state ? On which criteria ?
On Sun, Oct 1, 2017 at 12:12 PM, Marcus Eriksson wrote:
> I was just thinking that we should try really hard to avoid adding
> experimental features - they are experimental due
I was just thinking that we should try really hard to avoid adding
experimental features - they are experimental due to lack of testing right?
There should be a clear path to making the feature non-experimental (or get
it removed) and having that path discussed on dev@ might give more
visibility to
12 matches
Mail list logo
