The cost is in how many users you scare away
--
Jeff Jirsa
> On Jan 16, 2019, at 2:34 PM, Brandon Williams wrote:
>
> Also it costs us nothing to add it.
>
>> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad wrote:
>>
>> I'm +1 on the warning for two re
there was some issue with this and RTs recently, so I’m not
sure if it’s current state, but worth considering that this may be much better
on 3.0+
--
Jeff Jirsa
> On Jan 31, 2019, at 1:56 PM, Carl Mueller
> wrote:
>
> Situation:
>
> We use TWCS for a task history table
> > On Thu, Jan 31, 2019 at 8:11 PM Jonathan Haddad
> wrote:
> >
> >> In addition to what Jeff mentioned, there was an optimization in 3.4
> that
> >> can significantly reduce the number of sstables accessed when a LIMIT
> >> clause was used. This can
e the number of sstables accessed when a LIMIT
> > clause was used. This can be a pretty big win with TWCS.
> >
> >
> >
> http://thelastpickle.com/blog/2017/03/07/The-limit-clause-in-cassandra-might-not-work-as-you-think.html
> >
> > On Thu, Jan 31, 2019 at 5:5
Iterate over all of the possible time buckets.
On Fri, Feb 1, 2019 at 1:36 PM Carl Mueller
wrote:
> I'd still need a "all events for app_id" query. We have seconds-level
> events :-(
>
>
> On Fri, Feb 1, 2019 at 3:02 PM Jeff Jirsa wrote:
>
> > On Fr
There’s SO MUCH that needs to go out, let’s just get out what we have
--
Jeff Jirsa
> On Feb 2, 2019, at 5:35 PM, Benedict Elliott Smith
> wrote:
>
> CASSANDRA-14812 should probably land in this release, given that it is a
> critical bug, has been patch available for
+1
On Sat, Feb 2, 2019 at 4:38 PM Michael Shuler
wrote:
> I propose the following artifacts for release as 3.11.4.
>
> sha1: fd47391aae13bcf4ee995abcde1b0e180372d193
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.4-tentative
> Artifacts:
>
> https://re
+1 (to the release, I see no reason to force this to be EOL; leaving the
branch open has zero cost, and if a serious enough patch comes up, we'll
likely be happy we have the option to fix it).
On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler
wrote:
> *EOL* release for the 2.1 series. There will be
+1
On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler
wrote:
> I propose the following artifacts for release as 2.2.14.
>
> sha1: af91658353ba601fc8cd08627e8d36bac62e936a
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.14-tentative
> Artifacts:
>
> https://re
+1
On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler
wrote:
> I propose the following artifacts for release as 3.0.18.
>
> sha1: edd52cef50a6242609a20d0d84c8eb74c580035e
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.18-tentative
> Artifacts:
>
> https://re
+1
--
Jeff Jirsa
> On Feb 15, 2019, at 9:35 AM, Jonathan Ellis wrote:
>
> IMO "add a new compression class that has demonstrable benefits to Sushma
> and Joseph" is sufficiently noninvasive that we should allow it into 4.0.
>
> On Fri, Feb 15, 2019 at 10
> On Feb 26, 2019, at 8:26 AM, Stanislav Kozlovski
> wrote:
>
> Hey there Cassandra community,
>
> I work on a fellow open-source project - Apache Kafka - and there we have
> been fighting flaky tests a lot. We run Java 8 and Java 11 builds on every
> Pull Request and due to test flakines
Please
--
Jeff Jirsa
> On May 14, 2019, at 7:53 AM, Benedict Elliott Smith
> wrote:
>
> How would people feel about introducing a field for the (git) commit SHA, to
> be required on (Jira) commit?
>
> The norm is that we comment the SHA, but given this is the norm
Don’t delete that line.
Which version of Java are you using to compile
> On Jul 14, 2019, at 7:51 AM, Nimbus Lin wrote:
>
> TO: Genius Cassandra's developers,
>
> how to solve the 3 compile errors in AbstractRow.java?
>
> The 3 errors are all because the only 1 line code:
>
> "
I weakly prefer contrib.
On Thu, Aug 22, 2019 at 12:09 PM Marcus Eriksson wrote:
> Hi, we are about to open source our tooling for comparing two cassandra
> clusters and want to get some feedback where to push it. I think the
> options are: (name bike-shedding welcome)
>
> 1. create repos/asf/c
There have been people who have had operational issues related to MVs (many
of them around running repair), but the biggest concern is correctness.
It probably ultimately depends on what type of database you're running. If
you're running some sort of IOT / analytics workload and you just want
anot
+1
On Fri, Oct 25, 2019 at 7:18 AM Sam Tunnicliffe wrote:
> +1
>
> > On 24 Oct 2019, at 18:26, Michael Shuler wrote:
> >
> > I propose the following artifacts for release as 3.11.5.
> >
> > sha1: b697af87f8e1b20d22948390d516dba1fbb9eee7
> > Git:
> https://gitbox.apache.org/repos/asf?p=cassandr
+1
On Fri, Oct 25, 2019 at 7:18 AM Sam Tunnicliffe wrote:
> +1
>
> > On 24 Oct 2019, at 18:25, Michael Shuler wrote:
> >
> > I propose the following artifacts for release as 3.0.19.
> >
> > sha1: a81bfd6b7db3a373430b3c4e8f4e930b199796f0
> > Git:
> https://gitbox.apache.org/repos/asf?p=cassandr
+1
On Fri, Oct 25, 2019 at 7:18 AM Sam Tunnicliffe wrote:
> +1
>
> > On 24 Oct 2019, at 18:25, Michael Shuler wrote:
> >
> > I propose the following artifacts for release as 2.2.15.
> >
> > sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086
> > Git:
> https://gitbox.apache.org/repos/asf?p=cassandr
+1
On Fri, Oct 25, 2019 at 8:06 AM Jon Haddad wrote:
> +1
>
> On Fri, Oct 25, 2019 at 10:18 AM Sam Tunnicliffe wrote:
>
> > +1
> >
> > > On 24 Oct 2019, at 18:26, Michael Shuler
> wrote:
> > >
> > > I propose the following artifacts for release as 4.0-alpha2.
> > >
> > > sha1: ca928a49c68186b
On Fri, Jan 10, 2020 at 2:35 PM Benedict Elliott Smith
wrote:
>
> Yes, I also miss those fortnightly (or monthly) summaries that Jeff
> used to do. They were very useful "glue" in the community. I imagine they'd
> also make writing the board report easier.
>
> +1, those were great
>
>
>
I'll
On Fri, Jan 10, 2020 at 3:19 PM Jeff Jirsa wrote:
>
>
> On Fri, Jan 10, 2020 at 2:35 PM Benedict Elliott Smith <
> bened...@apache.org> wrote:
>
>>
>> Yes, I also miss those fortnightly (or monthly) summaries that Jeff
>> used to do. They were very us
olvement of the community. I'm sure everyone will be
>> supportive, but it would help to democratise the decision-making.
>> On 11/01/2020, 01:39, "Patrick McFadin" wrote:
>> Scott and I had a talk this week and we are starting the contributor
>> meetings on 1/22 as
Back to the original question in the thread - I think a critical pass through
open issues is warranted -
What hasn’t been triaged?
What is slated for 4.0 but unassigned ?
What is patch available but needs more engineering ?
What is ready to commit and uncommitted?
You’ve got the context to under
On Tue, Jan 21, 2020 at 7:41 PM Jonathan Koppenhofer
wrote:
> If someone isn't explicitly setting vnodes, and the default changes, it
> will vary from the number of assigned tokens for existing clusters, right?
> Won't this cause the node to fail to start?
>
Nope. You can have 32 tokens on some
On Thu, Jan 23, 2020 at 6:18 AM Jeremiah Jordan
wrote:
> Can’t you currently open a PR with the right commit message, have do
> review there with all comments posted back to JIRA, run CI on it and then
> merge it closing the PR? This is the basic workflow you are proposing yes?
>
>
Yes you can.
100% agree
François and team wrote a doc on testing and gating commits
Blake wrote a doc on testing and gating commits
Every release there’s a thread on testing and gating commits
People are the common factor every time. Nobody wants to avoid merging their
patch because someone broke a test else
t; > > too trivial, poisoning the well for third parties trying to find
> > > useful
> > > > information. If the comment wouldn't be made in Jira, it
> probably
> > > > shouldn't be made.
> > > > >>
> > > > >>
> &
On Fri, Jan 31, 2020 at 11:25 AM Joseph Lynch wrote:
> I think that we might be bikeshedding this number a bit because it is easy
> to debate and there is not yet one right answer.
>
https://www.youtube.com/watch?v=v465T5u9UKo
Hard to see an argument for CASSANDRA-2848 being in scope for 4.0 (beyond the
client proto change being painful for anything other than major releases).
> On Feb 17, 2020, at 12:43 PM, Jon Meredith wrote:
>
> My turn to give an update on 4.0 status. The 4.0 board created by Josh can
> be
> > completely misremembering this.
> >
> > -- Forwarded message -----
> > From: Jordan West
> > Date: Wed, Feb 19, 2020 at 10:13 AM
> > Subject: Re: 20200217 4.0 Status Update
> > To:
> >
> >
> > On Mon, Feb 17, 2020 at 12:52
This isn't an opinion for or against upgrading guava, just a note that the
two classes mentioned in that vulnerability are not actually in the
codebase:
jjirsa:cassandra jjirsa$ git checkout cassandra-3.11
Checking out files: 100% (3212/3212), done.)
Switched to branch 'cassandra-3.11'
Your branch
Adding my PMC binding -1 until Mick's comments are addressed.
On Fri, Mar 20, 2020 at 11:39 AM Mick Semb Wever wrote:
> > The vote will be open for 72 hours (longer if needed). Everyone who has
> > tested the build is invited to vote. Votes by PMC members are considered
> > binding. A vote pass
Someone once said:
"I heard the expression recently that “there are ten ways to do this, and
eight of them will work.” I think that applies to most of the code we
write. We don't need to spend a lot of time discussing which of the eight
is best; let’s trust the judgement of the original author a
+1
> On Apr 10, 2020, at 4:02 PM, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.0-alpha4 for release.
>
> sha1: d00c004cc10986fc41c2070f9c5d0007e03a45c3
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha4-tentative
> Maven Artif
I havent reviewed that code, but it's not surprising there would be
deprecated annotations in a major release. We *SHOULD* be deprecating
things that worked in 3.0/3.11 in 4.0, and removing them in a future
verison. We should only be removing them in 4.0 if they were originally
supported in 2.1/2.2
+1 (pmc, binding)
On Tue, Jun 16, 2020 at 9:19 AM Joshua McKenzie
wrote:
> Added unratified draft to the wiki here:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> I propose the following:
>
>1. We leave the vote open for 1 week (close at en
+1 (and present?)
> On Jun 20, 2020, at 8:12 AM, Joshua McKenzie wrote:
>
> Link to doc:
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> Change since previous cancelled vote:
> "A simple majority of this electorate becomes the low-watermark for
On Tue, Jun 30, 2020 at 1:46 PM Joshua McKenzie
wrote:
> We're just short of 98 tickets on the component since it's original merge
> so at least *some* work has been done to stabilize them. Not to say I'm
> endorsing running them at massive scale today without knowing what you're
> doing, to be c
+1
On Fri, Jul 10, 2020 at 7:22 AM Oleksandr Petrov
wrote:
> Proposing the test build of in-jvm dtest API 0.0.4 for release.
>
> Repository:
>
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.4
> Candidate SHA:
>
> https://github.com/apache/cassa
> On Jul 13, 2020, at 11:42 AM, Jon Haddad wrote:
>
> Support for Java 11 was added a long time ago, and it's been about 2 years
> since it was released (Sept 2018). Had we released Cassandra 4 close to
> that date, I'd be fine with keeping the status as experimental, but at this
> point I'm
Zgc
> On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote:
>
>
>> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote:
>>
>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even prod
>> ready in jdk11 , so what’s the motivation and what does the pro
+1
> On Jul 17, 2020, at 4:28 PM, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.0-beta1 for release.
>
> sha1: 972da6fcffa87b3a1684362a2bab97db853372d8
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative
> Maven Artifa
—
> > Robert Stupp
> > @snazy
> >
> > > On 14. Jul 2020, at 15:02, Jeff Jirsa wrote:
> > >
> > > Zgc
> > >
> > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote:
> > >>
> > >>
> > >>> On 14. J
Got it, thanks for the correction.
On Mon, Jul 20, 2020 at 4:28 PM Brandon Williams wrote:
> I believe you can run them on 11, but you can't build them on it.
>
> On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa wrote:
> >
> > I still dont get it, because you can
> On Jul 30, 2020, at 8:08 AM, Andrew Cobley (Staff)
> wrote:
>
> Apologies, I have not been involved in this process for a few years, but I
> saw this topic pass by and thought I would like to comment.
>
> I’m a lecturer in computer science and used C* in a couple of dev classes,
> some
I don't have any questions, but datastax folks: thanks for funding stuff
like this.
(I'd love to see it as a blog post, I'd also love to see people internalize
the negative feedback and assumed features and determine whether or not
people are working on the right things)
On Thu, Aug 27, 2020 at 1
+1
On Fri, Aug 28, 2020 at 7:19 AM Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0-beta2 for release.
>
> sha1: 56eadf2004399a80f0733041cacf03839832249a
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta2-tentative
> Maven Artifacts
+1
On Fri, Aug 28, 2020 at 6:37 AM Mick Semb Wever wrote:
> Proposing the test build of Cassandra 3.11.8 for release.
>
> sha1: 8b29b698630960a0ebb2c695cc5b21dee4686d09
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.8-tentative
> Maven Artifacts:
>
>
+1
On Fri, Aug 28, 2020 at 5:45 AM Mick Semb Wever wrote:
> Proposing the test build of Cassandra 2.2.18 for release.
>
> sha1: d4938cf4e488a9ef3ac48164a3e946f16255d721
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.18-tentative
> Maven Artifacts:
>
>
+1
On Fri, Aug 28, 2020 at 8:42 AM Mick Semb Wever wrote:
> Proposing the test build of Cassandra 2.1.22 for release.
>
> sha1: 94e9149c22f6a7772c0015e1b1ef2e2961155c0a
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.22-tentative
> Maven Artifacts:
> ht
+1
On Fri, Aug 28, 2020 at 7:43 AM Brandon Williams wrote:
> +1
>
> On Fri, Aug 28, 2020 at 8:09 AM Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 3.0.22 for release.
> >
> > sha1: 45331bb612dc7847efece7e26cdd0b376bd11249
> > Git:
> >
> https://gitbox.apache.org/repos/asf
> On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith
> wrote:
>
>
>>
>> As I understand Sankalp's primary (and quite reasonable) argument the last
>> time we discussed this
>
> The more significant cost to the project is distracting contributors focused
> on 4.0. The project is bandwi
I assumed it would be 3.0.x and 3.11.x
I don’t know why we’d make 3.0-4.0 unofficial/unsupported - there’s no
technical reason I’ve seen
> On Oct 8, 2020, at 9:21 PM, Anthony Grasso wrote:
>
> Hi Josh,
>
> This is a really good question. I agree with David about making sure this
> is cle
This is complicated and relatively few people on earth understand it, so
having little feedback is mostly expected, unfortunately.
My normal emotional response is "correctness is required, opt-in to
performance improvements that sacrifice strict correctness", but I'm also
sure this is going to sur
+1 (binding)
It's not a big deal, not worth killing the release, but 15299 / a7c4ba9eeec
introduced a build warning in a burn test, I'll open a JIRA for it in a bit
(unless someone ninjas it first).
On 2020/12/18 19:16:16, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0-be
No objection and strong agreement that it should happen with 4.0 for arm64
On Wed, Jan 20, 2021 at 12:44 PM Mick Semb Wever wrote:
> To get Cassandra 4.0 working on arm64 we have a number of dependencies
> we need to upgrade. See CASSANDRA-16384, CASSANDRA-16392 and
> CASSANDRA-15889.
>
> CASSA
SOME lightweight processing is possible with UDFs / UDAs:
http://www.planetcassandra.org/blog/user-defined-functions-in-cassandra-3-0
/
They're not directly comparable to Hbase coprocessors, but they allow some
computation on the server.
On 12/10/15, 11:02 PM, "hongbin ma" wrote:
>hi communi
As an operator, I’d imagine it’s mostly the same as always - stability will
vary by workload, so test with your workload until you’re confident.
If x.y.Z where Z >= 6 was basically the guideline most people used before, then
it’s probably worth considering 3.5 and 3.7 as worth testing in your sp
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/TokenMetadata.java#L731-L754
And
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/TokenMetadata.java#L60-L88
Cassandra keeps a map of joining and leaving nodes, and does e
https://github.com/hector-client/hector
https://github.com/Netflix/astyanax
http://doanduyhai.github.io/Achilles/
https://github.com/noorq/casser
https://github.com/impetus-opensource/Kundera
https://github.com/deanhiller/playorm
- Jeff ( Not affiliated with datastax )
On 6/3/16, 7:5
+1 (nonbinding) to at least announcing major architectural improvements on dev
email.
I don’t know that it’s going to help encourage more contributors like Chris
suggests, but it seems like at worst it won’t hurt, and certainly should help
make people aware of Jiras that would otherwise slip b
On 8/15/16, 2:15 PM, "Marvin Humphrey" wrote:
> Julian Hyde, who made the proposal, is active in the Apache Incubator …
>I propose that when a JIRA is created, we send an email to both dev@ and
>issues@. This will be an extra 40 emails per month on the dev list. I am
>really cautiou
There exists a #cassandra-dev IRC channel that’s historically been used by
developers discussing the project – while it’s public, it’s not archived, and
it’s not a mailing list. The ASF encourages all discussion to be archived, and
ideally, archived on a public mailing list.
Jake suggested,
+1 to both as well
On 8/26/16, 11:59 AM, "Tyler Hobbs" wrote:
>+1 on doing this and using ASFBot in particular.
>
>On Fri, Aug 26, 2016 at 1:40 PM, Jason Brown wrote:
>
>> @Dave ASFBot looks like a winner. If others are on board with this, I can
>> work on getting it up and going.
>>
>> On Fri,
I guess someone would have to open 3 different PRs (say, 2.2, 3.0, trunk), and
the committer would have 3 different commit messages to close each of them?
Anyone have examples of projects with branching strategies similar to ours
using github pull requests?
On 8/29/16, 6:26 AM, "Sylvain Lebr
26, 2016 at 12:28 PM, Edward Capriolo
>> >>>> > >>>>
>> >>>> wrote:
>> >>>>
>> >>>> One thing to watch out for. The way apache-gossip is setup the
>> >>>>> PR's get sent
If you wish to unsubscribe, send an email to
dev-unsubscr...@cassandra.apache.org
From: Farrukh Saeed
Reply-To: "dev@cassandra.apache.org"
Date: Tuesday, August 30, 2016 at 2:32 PM
To: "dev@cassandra.apache.org"
Subject: Re: Contribution to apache Cassandra wiki
Can someone help m
Can you describe the size and number of slaves we need to do things "right"?
How many cores? How much ram? How many slaves?
--
Jeff Jirsa
> On Sep 9, 2016, at 12:27 PM, Michael Shuler wrote:
>
> I have an ongoing INFRA ticket with the testing issues we've seen wh
On 9/9/16, 5:45 PM, "Dikang Gu" wrote:
>Hi,
>
>We have some big cluster (500+ nodes), they have 256 vnodes on physical
>host, which is causing a lot of problems to us, especially make the gossip
>to be in-efficient.
>
>There seems no way to change the number of vnodes on existing nodes, is
>the
We did 3.1.1 and 3.2.1, so there’s SOME precedent for emergency fixes, but we
certainly didn’t/won’t go back and cut new releases from every branch for every
critical bug in future releases, so I think we need to draw the line somewhere.
If it’s fixed in 3.7 and 3.0.x (x >= 6), it seems like you
fail:
>>>>
>>>> ERROR 05:32:09 Exiting due to error while processing commit log during
>>>> initialization.
>>>> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException:
>>>> Unexpected error deserializing mutatio
+1
On 9/15/16, 11:57 AM, "jak...@gmail.com on behalf of Jake Luciani"
wrote:
>I propose the following artifacts for release as 3.0.9.
>
>sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012
>Git:
>https://urldefense.proofpoint.com/v2/url?u=http-3A__git-2Dwip-2Dus.apache.org_repos_asf-3Fp-3Dcassandra
that parnew pause.
--
Jeff Jirsa
> On Sep 19, 2016, at 11:12 PM, Dikang Gu wrote:
>
> In our 2.1 cluster, I find that hints handoff is using a lot of memory on
> our proxy nodes, when delivering hints to a data node that was dead for 3+
> hours (our hints window is 3 hours
+1
On 2016-09-23 16:04 (-0700), Michael Shuler wrote:
> I propose the following artifacts for release as 2.2.8.
>
> sha1: e9fe96f404b6a936ac5dbceb8f3934fe0d098a97
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.8-tentative
> Artifacts:
> https://reposi
+1
On 2016-09-26 08:12 (-0700), Michael Shuler wrote:
> I propose the following artifacts for release as 3.9.
>
> sha1: c1fa21458777b51a9b21795330ed6f298103b436
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.9-tentative
> Artifacts:
> https://repository
+1
On 2016-09-26 07:52 (-0700), Michael Shuler wrote:
> I propose the following artifacts for release as 3.8.
>
> sha1: ce609d19fd130e16184d9e6d37ffee4a1ebad607
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.8-tentative
> Artifacts:
> https://repositor
+1
--
Jeff Jirsa
> On Sep 30, 2016, at 11:51 AM, Nate McCall wrote:
>
> I propose we begin the process of accepting the contribution of the
> dtest codebase (https://github.com/riptano/cassandra-dtest) into the
> project.
>
> Background discussion thread here:
>
+1
On 2016-10-05 16:09 (-0700), Michael Shuler wrote:
> I propose the following artifacts for release as 2.1.16.
>
> sha1: 87034cd05964e64c6c925597279865a40a8c152f
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.16-tentative
> Artifacts:
> https://re
That sounds awful, especially since you could just use SimpleStrategy with RF=1
and then bootstrap / decom would handle resharding for you as expected.
--
Jeff Jirsa
> On Oct 8, 2016, at 10:09 AM, Edward Capriolo wrote:
>
> I have contemplated using LocalStrategy as a "do it y
I'm sure that's what he meant, I just disagree that it sounds useful
--
Jeff Jirsa
> On Oct 8, 2016, at 10:33 AM, Vladimir Yudovin wrote:
>
> As far as I understand Edward meant to have option determinate actual storage
> node on client side, by driver, disreg
Let’s not get too far in the theoretical weeds. The email thread really focused
on low hanging tickets – tickets that need review, but definitely not 8099
level reviews:
1) There’s a lot of low hanging tickets that would benefit from outside
contributors as their first-patch in Cassandra (like
On 2016-10-20 13:26 (-0700), "J. D. Jordan" wrote:
> If you think of the tick tock releases as interim development releases I
> actually think they have been working pretty well. What if we continue with
> the same process and do 4.0.x as LTS like we have 3.0.x LTS.
>
> So you get 4.x releas
On 2016-10-20 14:21 (-0700), Jeremiah Jordan wrote:
> In the original tick tock plan we would not have kept 4.0.x around. So I am
> proposing a change for that and then we label the 3.x and 4.x releases as
> "development releases" or some other thing and have "yearly" LTS releases
> with .0
-1 , regression
On 11/2/16, 1:52 PM, "Nate McCall" wrote:
>[Copied from 3.10 thread]
>Sorry all. Changing my vote to -1 per my comment:
>https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D12867-3FfocusedCommentId-3D15630442-26page-3Dcom.atlassian.jira
-1, regression
On 2016-10-31 08:18 (-0700), Michael Shuler wrote:
> I propose the following artifacts for release as 3.10.
>
> sha1: a3828ca8b755fc98799867baf07039f7ff53be05
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative
> Artifacts:
> htt
Note also the work on https://issues.apache.org/jira/browse/CASSANDRA-9459 ,
reaching out to other “competitors” before major versions to ensure
compatibility and awareness.
I think there’s a ton of evidence supporting the assertion that
datastax-employed committers and PMC members acted in goo
I agree - thanks for sending it, Lukasz. I think we can use it as a great
learning opportunity - because nearly every point you made I find to be
factually and objectively wrong, and the fact that members of the ASF take it
at face value is part of the problem - poorly informed opinions on compl
fears that they'll simply disappear should be
put aside - they may not contribute all of their improvements, but they're
still contributing, and for that I thank them. As a member of the PMC, I
encourage people to try to become more involved. It's a complicated piece of
software, but
My first reaction to seeing this come in was to laugh - not because it's
funny, but because the only other thing I could think to do was cry. You've
misinterpreted or misunderstood almost everything in this post, and instead
of reflecting on your side of the interaction, you've attributed the
outco
I hope the other 7 members of the board take note of this response,
and other similar reactions on dev@ today.
When Datastax violated trademark, they acknowledged it and worked to
correct it. To their credit, they tried to do the right thing.
When the PMC failed to enforce problems, we acknowledge
Now that I have clarity on what can and can't be relayed to the community /
dev@, I'm going to reply to this email, and then I suspect I'm done for
today, because I'd rather watch football than reply to this anymore.
On Sat, Nov 5, 2016 at 6:30 AM, Mark Struberg
wrote:
> Having a bit insight ho
There exists a nearly unused mailing list, client-...@cassandra.apache.org [0].
This is a summary of the email threads over the past 12 months on that list:
1) ApacheCon Seville CFP Close notice
2) Datastax .NET driver question
3) Datastax Java driver question
4) FOSDEM announce
5) ApacheCon NA
‘Accepted’ JIRA status seems useful, but would encourage something more
explicit like ‘Concept Accepted’ or similar to denote that the concept is
agreed upon, but the actual patch itself may not be accepted yet.
/bikeshed.
On 11/7/16, 2:56 AM, "Ben Slater" wrote:
>Thanks Dave. The shepherd c
Also https://issues.apache.org/jira/browse/CASSANDRA-12676
--
Jeff Jirsa
> On Nov 4, 2016, at 11:51 AM, Jason Brown wrote:
>
> +1 to epaxos
>
>> On Fri, Nov 4, 2016 at 11:40 AM, Jonathan Haddad wrote:
>>
>> epaxos would be nice, it's been about 2 years
-1 as well, #12877
On 11/9/16, 5:20 AM, "Oleksandr Petrov" wrote:
>-1
>
>Sorry but I have to -1 that one, with the following explanation
>
>One of the features in 3.10 breaks SASI in quite a significant way. The
>issue was introduced in #11990 [1] and described in #12877 [2]. If there
>are mor
With 8 binding +1s (including myself), 3 non-binding +1, and no -1, the vote
passes, and we'll work to close out this list.
- Jeff
On 2016-11-06 21:11 (-0800), "Jeff Jirsa" wrote:
> There exists a nearly unused mailing list, client-...@cassandra.apache.org
> [0].
>
+1
--
Jeff Jirsa
> On Nov 11, 2016, at 5:36 PM, Michael Shuler wrote:
>
> I propose the following artifacts for release as 3.0.10.
>
> sha1: d6a3ef4863142c3f9fc1def911f28341fc78f2e8
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/
We’ll be voting in the very near future on timing of major releases and release
strategy. 4.0 won’t happen until that vote takes place.
But since you asked, I have ONE tick/tock (3.9) cluster being qualified for
production because it needs SASI.
- Jeff
On 11/17/16, 9:59 AM, "Jonathan Haddad"
+1
On 2016-11-18 10:08 (-0800), Michael Shuler wrote:
> I propose the following artifacts for release as 3.10.
>
> sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative
> Artifacts:
> https://reposit
101 - 200 of 475 matches
Mail list logo
