Re: Why does CockroachDB github website say Cassandra has no Availability on datacenter failure?

Marketing never lies. Ever

Re: Low hanging fruit crew

this. There are a few of us with a very good understanding of working Cassandra yet could use more exposure to the code base. We'll start getting out there and looking for things to review. Kurt Greaves k...@instaclustr.com www.instaclustr.com

Re: Low hanging fruit crew

o can help them through. Having said that I'm happy to be part of the so called LHF crew as soon as I'm qualified enough to do so. I'm currently full time on contributing to the C* project, so hopefuly it shouldn't be too long before I'm able to take on some of these duties. Kurt Greaves k...@insta

Re: Proposals for releases - 4.0 and beyond

yep +1 to this. The LTS release solves my previous concern

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

le stability is important if we push back large "core" changes until later we're just setting ourselves up to face the same issues later on. There should be enough uptake on the early releases of 4.0 from new users to help test and get it to a production-ready state. Kurt Greaves k...@instaclustr.com www.instaclustr.com

Re: Proposals for releases - 4.0 and beyond

Option 3 seems the most reasonable and the clearest from a user perspective. The main thing I'd be concerned about with a 6 month cycle would be how short a branch is supported for. Most users will be bound to a specific release for at least 2 years, and we still find bugs in 2.1 2 years since

Re: [VOTE] Release Apache Cassandra 3.10

Just raised https://issues.apache.org/jira/browse/CASSANDRA-12867 which affects 3.10 and 3.0.10. Appears to be a bug introduced by CASSANDRA-12060. Might want to consider it before releasing these versions. Kurt Greaves k...@instaclustr.com www.instaclustr.com On 31 October 2016 at 17:41

Re: rebuild constantly fails, 3.11

How much memory do these machines have? Typically we've found that G1 isn't worth it until you get to around 24G heaps, and even at that it's not really better than CMS. You could try CMS with an 8G heap and 2G new size. However as the oom is only happening on one node have you ensured there are

Re: rebuild constantly fails, 3.11

cc'ing user back in... On 12 Aug. 2017 01:55, "kurt greaves" <k...@instaclustr.com> wrote: > How much memory do these machines have? Typically we've found that G1 > isn't worth it until you get to around 24G heaps, and even at that it's not > really better than CMS. You

Re: State of Materialized Views

Thanks for the input Benjamin. Sounds like you've come to a lot of the same conclusions I have. I'm certainly keen on fixing up MV's and I don't really see a way we could avoid it, as I know they are already widely being used in production. I think we would have had a much easier time if we went

State of Materialized Views

wall of text inc. *tl;dr: *Aiming to come to some conclusions about what we are doing with MV's and how we are going to make them stable in production. But really just trying to raise awareness/involvement for MV's. It seems we've got an excess of MV bugs that pretty much make them completely

RE: CHANGES.txt

I agree that all patches should be added to changes.txt, just to rule out any ambiguities. When people look at Changes.txt it's usually to find something specific, not to browse the list of changes. Anything significant should make it into news.txt, which is more appropriate for users. changes.txt

Re: State of Materialized Views

I'm going to do my best to review all the changes Zhao is making under CASSANDRA-11500 , but yeah definitely need a committer nominee as well. On that note, Zhao is going to try address a lot of the current issues I listed above in #11500.​

Re: jira rights

I ran into this a few weeks ago. Basically contributors can assign any Cassandra ticket to anyone with an account, however non-contributors can't do anything. So you still have to get a contributor to assign you a ticket if you are not one yourself (or get added to contributors).

Re: [DISCUSS] Should we do a 2.2 release?

+1 what Jeff said.

Re: Potential block issue for 3.0.13: schema version id mismatch while upgrading

On 31 May 2017 at 03:41, Jeremiah D Jordan wrote: > If 3.0.13 causes schema mismatch on upgrade, then maybe we should pull > that and release 3.0.14 once 13559 is fixed. As that is a pretty bad place > to get into. i think that would be a good idea

Re: Proposal to retroactively mark materialized views experimental

> > So you’d rather continue to lie to users about the stability of the > feature rather than admitting it was merged in prematurely? It was merged prematurely, but a lot has changed since then and a lot of fixes have been made, and now it's really no more awful than any other component of

Re: Proposal to retroactively mark materialized views experimental

> > The flag name `cdc_enabled` is simple and, without adjectives, does not > imply "experimental" or "beta" or anything like that. > It does make life easier for both operators and the C* developers. I would be all for a mv_enabled option, assuming it's enabled by default for all existing

Re: Proposal to retroactively mark materialized views experimental

Lots of users are already using MV's, believe it or not in some cases quite effectively and also on older versions which were still exposed to a lot of the bugs that cause inconsistencies. 3.11.1 has come a long way since then and I think with a bit more documentation around the current issues

Re: CREATE INDEX without IF NOT EXISTS when snapshoting

Certainly would make sense and should be trivial. here is where you want to look. Just create a ticket for it and prod here for a reviewer once

Re: Using SCT to test cassandra clusters

Thanks Roy, this actually looks pretty interesting. It seems that only AWS is supported for Cassandra, and a lot of the code is obviously geared towards scylla (e.g nemesis). Do you have any idea how much works w.r.t Cassandra? On 8 October 2017 at 17:00, Roy Dahan wrote: >

Re: Proposal to retroactively mark materialized views experimental

Well this is all terribly interesting. I was actually going to get some discussion going about this during my talk, which unfortunately didn't happen, but I'll take this opportunity to push my agenda. My 99 cents: *tl;dr: we should probably just focus on not releasing completely broken features

Re: [PROPOSAL] Migrate to pytest from nosetests for dtests

+1nb, Never been that fond of nose from a usability perspective, and I wouldn't be surprised if at least some of the problems running dtests were related to issues in nose. I can't imagine it would be a lot of work to port to py.test, if someone wants to do it they can go right ahead. On 29

Reviewer for LWT bug

Need a reviewer for CASSANDRA-14087 Pretty straight forward, we just get an NPE when comparing against a frozen collection which is null and we expect a specific collection. Anyone with a bit of knowledge around ColumnCondition.java should

Re: In need of reviewers

lution = unresolved AND status in ("Patch > Available", "Awaiting Feedback") AND reviewer is EMPTY ORDER BY updated > DESC > > On Fri, May 11, 2018 at 6:43 AM, kurt greaves <k...@instaclustr.com> > wrote: > > > We've got a bunch of tickets that ar

In need of reviewers

We've got a bunch of tickets that are either in need of review or just a bit of feedback. Would be very grateful for any help here :). Bugs: https://issues.apache.org/jira/browse/CASSANDRA-14365 https://issues.apache.org/jira/browse/CASSANDRA-14204

Re: Resource Intensive and Upgrade tests (Dtest Cassandra)

Moving thread to dev. We have setup a dtest environment to run against Cassandra db version > 3.11.1 and 3.0.5 > During the test run we see that tests under the category of > Resource intensive and Upgrade tests > Are skipped by default during the collection phase. FWIW you can see these results

3.11.3

We probably need to release 3.11.3 at some point soon because there's some pretty major bug fixes in there and interest has been expressed multiple times now for a release. Currently the only tickets marked for 3.11.3 that aren't complete are: https://issues.apache.org/jira/browse/CASSANDRA-14355

Re: [DISCUSS] Cassandra and future Java

n #9608 and > already merged into 4.0. Downloads and packages for 4.0 would be > released for Java 8, while running 4.0 with Java 11 would produce a > warning message indicating that it's experimental. > > > On 30.05.2018 08:54, kurt greaves wrote: > > So for anyo

Re: [DISCUSS] Cassandra and future Java

So for anyone that missed it, Java 11 will be released in September 2018. I'd prefer we target one Java release only. This is purely because we don't have the capacity or capability to test both releases. We hardly do a good enough job as it is of testing and lumping another JVM into the mix is

Re: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

Seems pretty straightforward to me. Create a python 3 version as soon as possible and make it available, keep the python 2.7 version as default until the next major release after 4.0 (assuming around/after python 2.7 EOL), then switch default and leave continued support for 2.7 cqlsh up to the

Re: 3.11.3

list would be great. >> >> On Wed, Jun 6, 2018 at 5:22 AM, kurt greaves >> wrote: >> >> We probably need to release 3.11.3 at some point soon because there's some >>> pretty major bug fixes in there and interest has been expressed multiple >>&

Re: Tombstone passed GC period causes un-repairable inconsistent data

We've seen this before but couldn't tie it to GCGS so we ended up forgetting about it. Now with a reproducible test case things make much more sense and we should be able to fix this. Seems that it's most certainly a bug with partition deletions and handling of GC grace seconds. It seems that the

Re: Testing 4.0 Post-Freeze

ng/reviewing bug fixes > for previous versions as well correct? > > I’d expect so – and to take it a step further, it’s likely that this rigor > will result in us identifying serious issues that were not regressions in > 4.0 warranting backports. As with any investment in testing / validation,

Re: Testing 4.0 Post-Freeze

tl;dr: +1 for committing to testing + bugfixing after feature freeze, but I can't really see how changing the branching strategy is going to have any impact at all. I really don't think it's a big deal. People will work based on whatever priorities they've been assigned, regardless of what you do

Re: Testing 4.0 Post-Freeze

ue, Jul 3, 2018 at 10:09 PM kurt greaves wrote: > > > > > > > but by committing to reserving trunk for stabilizing changes until the > > > beta, we focus our effort on polishing and delivering the release. > > > > No, committing to testing, bug fixing, a

Re: CASSANDRA-8527

I think that's a good idea for 4.x, but not so for current branches. I think as long as we document it well for 4.0 upgrades it's not so much of a problem. Obviously there will be cases of queries failing that were previously succeeding but we can already use tombstone_failure|warn_threshold to

Re: range queries on partition key supported?

> > So that means more than one nodes can be selected to fulfill a range query > based on the token, correct? Yes. When doing a token range query Cassandra will need to send requests to any node that owns part of the token range requested. This could be just one set of replicas or more,

Re: cpp driver warning for create keyspace statement

Seems like it might be a bug in the driver. Can you insert some data using the driver and query it from that datacenter either via the driver specifying a DC aware load balancing policy against DC-Ffm-2 with consistency LOCAL_ONE? or if that doesn't work, using cqlsh on a node in that datacenter

Re: [VOTE] Release Apache Cassandra 3.11.2

May as well just recut and include it IMO. Sure, the issue is work-aroundable, but in a pretty terrible way. Only a few hours will be lost (sorry Michael :/)​

Roadmap for 4.0

Hi friends, *TL;DR: Making a plan for 4.0, ideally everyone interested should provide up to two lists, one for tickets they can contribute resources to getting finished, and one for features they think would be desirable for 4.0, but not necessarily have the resources to commit to helping with.*

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

> > ​ReadCommandTest is still not passing. I would be a happy maintainer if > someone could step up and analyze and contribute a patch; I will review. Having a look. Appears to be just a case of using the same CF for multiple tests and metrics (tombstone histograms) aren't cleared in between.

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

CASSANDRA-14234 <https://issues.apache.org/jira/browse/CASSANDRA-14234> patch in for ReadCommandTest if anyone wants to take a look. On 14 February 2018 at 00:45, kurt greaves <k...@instaclustr.com> wrote: > ​ReadCommandTest is still not passing. I would be a happy maintainer if &

Re: Release votes

It seems there has been a bit of a slip in testing as of recently, mostly due to the fact that there's no canonical testing environment that isn't flaky. We probably need to come up with some ideas and a plan on how we're going to do testing in the future, and how we're going to make testing

Re: Why isn't there a separate JVM per table?

> > ... compaction on its own jvm was also something I was thinking about, but > then I realized even more JVM sharding could be done at the table level. Compaction in it's own JVM makes sense. At the table level I'm not so sure about. Gotta be some serious overheads from running that many

Re: How to fetch replication factor of a given keyspace

Did you look at how status fetches and initialises the keyspace? Have a look at org.apache.cassandra.service.StorageService#effectiveOwnership. It uses a keyspace and its RF to measure ownership. The same method should work for any nodetool command that needs a keyspace. Note that depending on

Re: Proposal: github pull requests for all code changes

It would definitely be nice if PR's were made against the actual repo. Makes commenting/reviewing code a lot easier. I'd say as long as PR's are kept permanently (after closing) so we can go back and look over comments/patches would be a big plus. Not a fan of going through JIRA tickets and

Re: [VOTE] Release Apache Cassandra 3.11.3 (Take 2)

+1 nb On Fri., 27 Jul. 2018, 00:20 Sam Tunnicliffe, wrote: > +1 > > On 25 July 2018 at 08:16, Michael Shuler wrote: > > > I propose the following artifacts for release as 3.11.3. > > > > sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0 > > Git: > >

Re: [VOTE] Release Apache Cassandra 2.2.13

+1 nb On Fri., 27 Jul. 2018, 00:20 Sam Tunnicliffe, wrote: > +1 > > On 25 July 2018 at 08:17, Michael Shuler wrote: > > > I propose the following artifacts for release as 2.2.13. > > > > sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8 > > Git: > >

Re: [VOTE] Release Apache Cassandra 3.0.17 (Take 2)

+1 nb On Fri., 27 Jul. 2018, 00:20 Sam Tunnicliffe, wrote: > +1 > > On 25 July 2018 at 08:17, Michael Shuler wrote: > > > I propose the following artifacts for release as 3.0.17. > > > > sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6 > > Git: > >

Re: GitHub PR ticket spam

+1 > Or perhaps we should require committers to summarise in the comments. For > most tickets, perhaps just stating ’nits from GitHub comments’. But for > any complex tickets, summarising the conclusions of any unexpected logical > or structural discussion would be really helpful for posterity.

Re: URGENT: CASSANDRA-14092 causes Data Loss

I definitely think we should include it in 4.0. TBH I think it's reasonable for it to get done after the feature freeze seeing as it is a bug. On 17 August 2018 at 21:06, Anuj Wadehra wrote: > Hi, > > I think CASSANDRA-14227 is pending for long time now. Though, the data > loss issue was

Re: Side Car New Repo vs not

+1 separate repo. I think in-tree only works if you're *not* supporting multiple versions and each sidecar release is directly tied to a corresponding C* release. Considering this case is also completely achievable in a separate repo anyway with minimal overhead we may as well start that way and

Re: Reaper as cassandra-admin

2c: There's a lot to think about here, and as Blake already mentioned most people don't have time to dedicate a lot of thought to this at the moment. There appear to be a lot of voices missing from the discussion, and I think it's pretty clear this isn't super tied to the freeze, so maybe we

Re: RangeAwareCompaction for manual token management

I've had similar thoughts in the past about RACS and manual tokens. I think it would be a good idea to be able to split it based on some configurable factor other than vnodes. I think Marcus may have already addressed this to some extent as well but if not it's theoretically possible. On 20 July

Re: JIRAs in Review

Cheers Dinesh, not too worried about that one in 4.0's case though as it's a bug but it will need a committer. As for improvements for 4.0: https://issues.apache.org/jira/browse/CASSANDRA-13010 - More verbose nodetool compactionstats. Speaks for itself.

Re: TTL of paxos table

It's just that compaction hasn't occured. TTL works even though GCGS is 0. There's been multiple discussions around this in the past, but we haven't come to a consensus yet though. Some proposals to change compaction strategy, some want to make it customisable. Treating paxos as sub-tables has

Re: [VOTE] Release Apache Cassandra 2.2.13

Actually taking back my +1, seems like we've got a fair amount of dtests (at least 7) failing consistently on 2.2, and another one that's very flaky. Last completed runs are here: https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-2.2-dtest/116/testReport/

Re: [VOTE] Release Apache Cassandra 2.2.13

+1 nb On Wed., 4 Jul. 2018, 03:26 Brandon Williams, wrote: > +1 > > On Mon, Jul 2, 2018 at 3:10 PM, Michael Shuler > wrote: > > > I propose the following artifacts for release as 2.2.13. > > > > sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645 > > Git:

Re: Roadmap for 4.0

> > Earlier than I’d have personally picked, but I’m +1 too This but +1. On 5 April 2018 at 03:04, J. D. Jordan wrote: > +1 > > > On Apr 4, 2018, at 5:06 PM, Nate McCall wrote: > > > > Top-posting as I think this summary is on point - thanks,

Re: [Discuss] patch review virtual hackathon

I like the idea and we would be willing to take part (no committers here but I'm sure we can help). I think it better to pick some JIRAs per 2-3 weeks and have people review > them. In my experience, it is hard to synchronize all people across > companies during one 72 hour slot. It is hard,

Re: [Discuss] patch review virtual hackathon

to completion. It's unlikely we'd end up with many commits after 72 hours, purely because any feedback may take longer than that to be actioned, but that doesn't mean our time is wasted. On 6 April 2018 at 05:09, kurt greaves <k...@instaclustr.com> wrote: > I like the idea and we would b

Re: Roadmap for 4.0

> > Lay our cards on the table about what we want included in 4.0 and work to > get those in Are you saying we're back to where we started?  For those wanting to delay, are we just dancing around inclusion of > some pet features? This is fine, I just think we need to communicate > what we

Re: Roadmap for 4.0

> > I'm also a bit sad that we seem to be getting back to our old demons of > trying > to shove as much as we possibly can in the next major as if having a > feature > miss it means it will never happen. That wasn't the intention of this thread, but that's the response I got. Thought I made it

Re: Roadmap for 4.0

> > In thinking about this, what is stopping us from branching 4.0 a lot > sooner? Like now-ish? This will let folks start hacking on trunk with > new stuff, and things we've gotten close on can still go in 4.0 Agree with Jeff here that this is not necessary. The branch point should be the

Re: Roadmap for 4.0

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

Re: Roadmap for 4.0

September also works for Instaclustr. On Fri., 13 Apr. 2018, 08:27 Jon Haddad, wrote: > Sept works for me too. I’ll be involved in the validation process before > the cutoff date. > > > > On Apr 12, 2018, at 3:17 PM, Carlos Rolo wrote: > > > > I will

Re: Roadmap for 4.0

> > So long as non-user-visible improvements, including big ones, can still go > in 4.0 at that stage, I’m all for it. My understanding is that after June 1st the 4.0 branch would be created and would be bugfix only. It's not really a feature freeze if you allow improvements after that, which is

Re: Repair scheduling tools

Vnodes is related and because we made it a default lots of people are using it. Repairing a cluster with vnodes is a catastrophe (even a small one is often problematic), but we have to deal with it if we build in repair scheduling. Repair scheduling is very important and we should definitely

Re: Roadmap for 4.0

> > I also don't see a place for minor releases as they exist today. It seems > like they are almost all the overhead of a major release with unnecessary > restrictions on what is possible. Yeah this, I've never heard of anything that we don't do in "minors", and it seems to me that everyone

Re: Quantifying Virtual Node Impact on Cassandra Availability

Great write up. Glad someone finally did the math for us. I don't think this will come as a surprise for many of the developers. Availability is only one issue raised by vnodes. Load distribution and performance are also pretty big concerns. I'm always a proponent for fixing vnodes, and removing

Re: Evolving the client protocol

> > 1. The protocol change is developed using the Cassandra process in a JIRA > ticket, culminating in a patch to doc/native_protocol*.spec when consensus > is achieved. I don't think forking would be desirable (for anyone) so this seems the most reasonable to me. For 1 and 2 it certainly makes

Re: Roadmap for 4.0

Seems to me we should put September first to an official vote so we can finish up with this mess. On 13 April 2018 at 02:27, Rahul Singh wrote: > I can commit some resources on my team - especially as we onboard some of > our summer apprentices. > > I have some

Re: Proposing an Apache Cassandra Management process

For anyone looking Dinesh made a ticket already: CASSANDRA-14395 On 18 April 2018 at 18:14, Vinay Chella wrote: > This is a good initiative. We have advocated for and run a sidecar for the > past 5+ years, and

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

I say we give it a few weeks and let adoptopenjdk make an official statement before we make any kind of plan. We're not in a great rush. On Mon., 26 Mar. 2018, 05:49 Carl Mueller, wrote: > And here we go! > > from here: >

Re: Empty partition keys allowed in MV, but not in normal table

Yeah definitely a problem there. Can you create a JIRA for it? On Sat., 24 Mar. 2018, 11:00 Duarte Nunes, wrote: > Hi, > > Given the following table: > > cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy', > 'replication_factor': 1}; > cqlsh> create

Re: Paying off tech debt and correctly naming things

As someone who came to the codebase post CQL but prior to thrift being removed, +1 to refactor. The current mixing of terminology is a complete nightmare. This would also give a good opportunity document a lot of code that simply isn't documented (or incorrect). I'd say it's worth doing it in

Re: Website front page broken links

A ticket already exists that covers this, with a patch. just needs some consensus around the third party page. https://issues.apache.org/jira/browse/CASSANDRA-14128 On 19 Mar. 2018 18:26, "Hannu Kröger" wrote: > Hello, > > I created this ticket >

Re: Debug logging enabled by default since 2.2

On the same page as Michael here. We disable debug logs in production due to the performance impact. Personally I think if debug logging is necessary for users to use the software we're doing something wrong. Also in my experience, if something doesn't reproduce it will not get fixed. Debug

Re: Action Required: We are sunsetting CircleCI 1.0 on August 31, 2018

Not that much gets committed to 2.1 and 2.2 anymore, but is this also true for those branches? On 27 February 2018 at 22:58, Michael Kjellman wrote: > FYI: we're already fully on circleci 2.0 for the 3.0, 3.11, and trunk > branches so no action required for us here! > >

Re: CASSANDRA-13241 lower default chunk_length_in_kb

I think if we're going to drop it to 16k, we should invest in the compact sequencing as well. Just lowering it to 16k will have potentially a painful impact on anyone running low memory nodes, but if we can do it without the memory impact I don't think there's any reason to wait another major

Re: QA signup

It's pretty much only third party plugins. I need it for the LDAP authenticator, and StratIO's lucene plugin will also need it. I know there are users out there with their own custom plugins that would benefit from it as well (and various other open source projects). It would make it easier,

Re: [DISCUSS] changing default token behavior for 4.0

+1. I've been making a case for this for some time now, and was actually a focus of my talk last week. I'd be very happy to get this into 4.0. We've tested various num_tokens with the algorithm on various sized clusters and we've found that typically 16 works best. With lower numbers we found

Re: Measuring Release Quality

I'm interested. Better defining the components and labels we use in our docs would be a good start and LHF. I'd prefer if we kept all the information within JIRA through the use of fields/labels though, and generated reports off those tags. Keeping all the information in one place is much better

Re: Proposing an Apache Cassandra Management process

Is this something we're moving ahead with despite the feature freeze? On Sat, 22 Sep 2018 at 08:32, dinesh.jo...@yahoo.com.INVALID wrote: > I have created a sub-task - CASSANDRA-14783. Could we get some feedback > before we begin implementing anything? > > Dinesh > > On Thursday, September

Re: Moving tickets out of 4.0 post freeze

Yeah so lets not derail any further and just put them all to 4.x (as I'm sure OP originally intended) and we can figure out versioning later. On Tue, 25 Sep 2018 at 12:07, Mick Semb Wever wrote: > > > > > I'm totally spitballing here on possible uses of meaningful minors. > > Continuing the

Re: [DISCUSS] changing default token behavior for 4.0

Sounds good to me. I'm going to play around with the algorithm and actually record some numbers/evidence over the next week to help us decide. On Tue, 25 Sep 2018 at 05:38, Joseph Lynch wrote: > I am a big fan of lowering the default number of tokens for many > reasons (availability, repair,

Re: Moving tickets out of 4.0 post freeze

My JIRA experience tells me it would be better to do a blanket update and then go back and fix anything that shouldn't have been updated. Shouldn't be hard that way either because everyones inbox will be flooded with emails, so as long as we all sanity check what got changed we should catch most

Re: [DISCUSS] changing default token behavior for 4.0

g Holdings Inc. (NASDAQ: BKNG) > > > > > > On Sat, Sep 22, 2018 at 8:12 PM Jonathan Haddad > wrote: > > > >> Is there a use case for random allocation? How does it help with > testing? I > >> can’t see a reason to keep it around. > >> &g

Re: [DISCUSS] changing default token behavior for 4.0

foreseeing the "new defaults don't work for my edge case" problem. On Sun., 23 Sep. 2018, 04:12 Jonathan Haddad, wrote: > Is there a use case for random allocation? How does it help with testing? I > can’t see a reason to keep it around. > > On Sat, Sep 22, 2018 at 3:06 AM kurt gr

Re: Measuring Release Quality

t should be a huge > job to come up with a proposal - though we might need to organise a > community effort to clean up the JIRA history! > > It would be great if we could get a few more volunteers from other > companies/backgrounds to participate. > > > > On 22 Sep 2018, at

Re: Request to review feature-freeze proposed tickets

Thanks Vinay. While I suspect this will be subject to heated debate, I'm also for this. The time to review for this project is incredibly demotivating, and it stems from a lack of contributors that are interested in the general health of the project. I think this can be quite easily remedied by

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

In the previous thread we seemed to come to the conclusion it would be under the same project with same committers/pmc. I don't know if sending it through incubation changes that? On Wed., 12 Sep. 2018, 13:03 Jeremy Hanna, wrote: > I don’t know if others have this same question, but what does

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

+1. I do share the same concerns as Sylvain, but I think it's important we get more driver experience/exposure in the project, as it seems lacking since datastax moved off, and I don't think this will be something we can just leave to the userbase to solve. I'm definitely looking to contribute as