On Thu, 2011-09-22 at 23:34 +0530, Tharindu Mathew wrote:
I managed to modify the Hadoop-Cassandra integration to start with a
column of a CF used for indexing.
Are you chasing CASSANDRA-2878 here?
The above issue is waiting on CASSANDRA-1600 which in turn in waiting on
On 17 August 2016 at 03:47, Benedict Elliott Smith
> What this project really needs, and the board is chomping at the bit about,
> is diversity. The fact is, right now DataStax does 95% of the substantive
> development on the project, and so they make all the
Totally agree with all the frustrations felt by Jon here.
Here's a proposal for 4.0 and beyond: that is puts together the comments
from Benedict, Jon, Tyler, Jeremy, and Ed;
- keep bimonthly feature releases,
- revert from tick-tock to SemVer numbering scheme,
- during the release vote
On 15 July 2016 at 16:38, jason zhao yang
> May I ask is there any plan of extending functionalities related to
I had needs for this in the past and my questioning always seemed to
eventuate to answers along the lines of this should be
On 22 September 2016 at 03:34, Michael Kjellman <
> They can both live in harmony and they both serve a purpose.
Thanks for writing that Michael.
I'm a big fan of assert statements and have over the years seen them add
value and stability to projects
> So I’m not sure what we can do here, other than perhaps create some sort
> of dashboard
> to show tickets with unassigned reviewers, and tickets with overdue
A dashboard would certainly be helpful.
What would also be helpful though is to hear some of the ways triage of
We should continue with 3.X until all the 4.0 blockers have been
>> committed - and there are quite a few of them remaining yet.
And… are we right to presume that all the "roadmap 4.0" issues that don't
break any compatibility will be released in the 3.X tock releases leading
up to 4.0?
On 16 November 2016 at 11:45, Aleksey Yeschenko
> Doesn’t matter what the original plan was. We should continue with 3.X
> until all the 4.0 blockers have been
> committed - and there are quite a few of them remaining yet.
Thanks for the clarity, the quick
On 19 November 2016 at 10:49, Jeff Jirsa wrote:
> Option #3: Sylvain proposed  feature / testing / stable branches, Y
> cadence for releases, X month rotation from feature -> testing -> stable ->
> EOL (X to be determined). This is similar to an Ubuntu/Debian like
On 3 October 2017 at 04:57, Aleksey Yeshchenko wrote:
> The idea is to check the flag in CreateViewStatement, so creation of new
> MVs doesn’t succeed without that flag flipped.
> Obviously, just disabling existing MVs working in a minor would be silly.
> As for the warning -
> > CDC sounds like it is in the same basket, but it already has the
> > `cdc_enabled` yaml flag which defaults false.
> I went this route because I was incredibly wary of changing the CL
> code and wanted to shield non-CDC users from any and all risk I
> reasonably could.
This approach so far
> We propose that between the September freeze date and beta, a new branch
> would not be created and trunk would only have bug fixes and performance
> improvements committed to it.
+1, like really yes!! because it's a step towards a more stable-master
If trunk is focused on
> I find this a bit annoying while subscribed to commits@,
> especially since we created pr@ for these kind of messages. Also I don't
> really see any value in mirroring all github comments to the ticket.
I agree with you Stefan. It makes the jira tickets quite painful to read. And I
> > Great idea. +1 to moving it to the work log.
This is working now.
See eg https://issues.apache.org/jira/browse/CASSANDRA-12926
(which I hijacked for testing and the comments in the PR have since been
> Great idea. +1 to moving it to the work log.
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail:
> We are also interested in contributing to the blog, what's the process?
it's part of the website,
To unsubscribe, e-mail:
> > contributions should be evaluated based on the merit of code and their
> > value add to the whole offering. I hope it does not matter whether that
> > contribution comes from PMC member or a person who is not a committer.
> I hope this goes without saying.
What do we mean "support multiple JDKs" ?
Are we talking Run-time or Compile-time?
> If we support multiple JDKs, at a minimum we should compile code against
> those JDKs.
Why? I really don't get that logic.
There's a cost-optimisation here in reducing what we have to support.
> However, in addition to using such a
> tool, I believe, when we make a release, we should build against the actual
> JDKs we support (that way, we are not making a release just based on the
> result of an external tool), and we should be able to optionally run UTs
> and DTests against the JDK
> the argument that something new should be written because an existing project
> has tech debt, and we'll do it the right way this time, is a pretty common
> software engineering mistake. The thing you’re replacing usually needs to
> have some really serious problems to make it worth
On Fri, 17 Aug 2018, at 14:27, Sankalp Kohli wrote:
> I am bumping this thread because patch has landed for this with repair
We are looking to contribute Reaper to the Cassandra project.
Looking at the patch it's very similar in its base design already, but Reaper
> Is there a roadmap or release schedule, so we can get an idea of what
> the Reaper devs have planned for it?
there's no roadmap per se, as it's open-source and it's the contributions as
they come that make it.
What I know that's in progress or been discussed is:
> Can you get all of the contributors cleared?
> What’s the architecture? Is it centralized? Is there a sidecar?
Working on it Jeff. Contributors are close to cleared. Copyright is either
Spotify or Stefan, both whom have CLAs in place with ASF.
Licenses of all npm dependencies are good.
> > There's a cost-optimisation here in reducing what we have to support.
> I agree and animal sniffer is a great way to ferret out obvious issues.
> I am not against using animal sniffer. I'm concerned that there are
> various incompatibilities between JDK versions and I am not 100%
> How would we be sure users will never encounter bugs unless we build
> against that JDK?
Apache Cassandra does not distribute JDK1.7 built releases.
The only way a user could repeat such a bug is if they have built C* themselves.
I don't think the project should be responsible for every
could you clear a few things up for me…
> C* 2.2
> > I'm still a bit confused as to what's the benefit in compiling with
> > jdk1.7 and then testing with jdk1.7 or jdk1.8
> I meant two separate workflows for each JDK i.e.
> Workflow1: Build against jdk1.7, and optionally run
> How can we continue moving this forward?
> Mick/Jon/TLP folks, is there a path here where we commit the
> Netflix-provided management process, and you augment Reaper to work with it?
> Is there a way we can make a larger umbrella that's modular that can
> support either/both?
> Periodic SNAPSHOT builds sounds great. I'd feel much better about builds
> published as date- or SHA-stamped snapshots / nightlies rather than
> calling them alphas at this point, as everyone's testing work is
> beginning. Can someone offer details on what would need to be done to
> We have done all this for previous releases and we know it has not worked
> well. So how giving it one more try is going to help here. Can someone
> outline what will change for 4.0 which will make it more successful?
I (again) agree with you Sankalp :-)
Why not try something new?
> Vote will be open for 72 hours.
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>>> is hard to protect against regression. In fact, just looking at the
> >>>>> callback shows two instances of debug log in the client request path
> >>>>> (exercise for the reader to “git blame”).
> >>>>>> Either we can go clean up all the surprises that leaked through, or
> >>>>> can turn off debug and start backing out some of the changes in
> >>>>> Putting stuff like compaction in the same bucket as digest mismatch
> >>>>> gossip state doesn’t make life materially better for most people.
> >>>>>> --
> >>>>>> Jeff Jirsa
> >>>>>>> On Mar 18, 2018, at 11:21 AM, Jonathan Ellis <jbel...@gmail.com>
> >>>> wrote:
> >>>>>>> That really depends on whether you're judicious in deciding what to
> >>>> log
> >>>>> at
> >>>>>>> debug, doesn't it?
> >>>>>>> On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman <
> >>>> kjell...@apple.com>
> >>>>>>> wrote:
> >>>>>>>> +1. this is how it works.
> >>>>>>>> your computer doesn’t run at debug logging by default. your phone
> >>>>> doesn’t
> >>>>>>>> either. neither does your smart tv. your database can’t be
> running at
> >>>>> debug
> >>>>>>>> just because it makes our lives as engineers easier.
> >>>>>>>>> On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski <
> >>>>>>>> a...@thelastpickle.com> wrote:
> >>>>>>>>> It's a tiny bit unusual to turn on debug logging for all users by
> >>>>> default
> >>>>>>>>> though, and there should be occasions to turn it on when facing
> >>>> issues
> >>>>>>>> that
> >>>>>>>>> you want to debug (if they can be easily reproduced).
> >>>>>>> --
> >>>>>>> Jonathan Ellis
> >>>>>>> co-founder, http://www.datastax.com
> >>>>>>> @spyced
> >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
Mick Semb Wever
The Last Pickle
Apache Cassandra Consulting
> But I'll try to put together a strawman proposal for the doc(s) over the
I've thrown something quickly together here:
> Can you share the link to cwiki if you have started it ?
But I'll try to put together a strawman proposal for the doc(s) over the
To unsubscribe, e-mail:
> > On Sep 27, 2018, at 7:35 PM, Mick Semb Wever wrote:
> > Reaper,
> I have looked at this already.
> > Priam,
> I have looked at this already.
> > Marcus Olsson's offering,
> This isn't OSS.
> > CStar,
> Mick - could you enumerate the list of tools you mentioned earlier?
Dinesh, quickly the following come to mind…
Marcus Olsson's offering,
Then there's a host of command line tools like:
ctop (was awesome, but is it maintained anymore?),
Sorry about the terrible english in my last email.
> On the target audience:
> For developers building automation around testing and
> validation, it’d be great to have a common build to work from rather
> than each developer producing these builds themselves.
Sure. My question
> I'm totally spitballing here on possible uses of meaningful minors.
Continuing the splitballing…
What about aligning native protocol or sstable format changes with the minor
> Regardless, the OP's statement that new features and improvements should go
> to 4.0.x seems wrong
> Most of the discussion and work was done off the mailing list - there's a
> big risk involved when folks disappear for months at a time and resurface
> with big pile of code plus an agenda that you failed to loop everyone in
Given all the discussions that have been had offline
> >> wrote:
> >> Thanks for starting this, Mick. I will flesh it out.
> >> Dinesh
> >> On Sunday, October 21, 2018, 1:52:10 AM PDT, Mick Semb Wever
> >> wrote:
The docs for Cassandra-3.11.3 have been added to the website:
These are not linked to from anywhere.
Next step it to regenerate the docs for Cassandra-4.0 (latest). I'll do this
next week if no one objects.
> Next step it to regenerate the docs for Cassandra-4.0 (latest). I'll do
> this next week if no one objects.
This has been done by Joey Lynch, Anthony Grasso and myself .
> a) list and link to the different versions of the docs
A very basic
Regarding the warning, we might add it at least in 3.11, since for that
version the property to enable SASI is going to be present but not disabled
by default. WDYT?
I'm -0 on this.
A single line warning in the logs on the sasi creation won't be noticed by many
A cqlsh warning only
> The purpose for this thread is discussing whether we want to add this
> warning, the config property and, more controversially, if we want to set
> SASI as disabled by default in trunk.
I'm +1 on everything, except the warning.
I think if we add the config property and it's disabled in
> 1: Component. (A) Multi-select; (B) Cascading-select
> 2: Labels: leave alone +1/-1
> 3: No workflow changes for first/second review: +1/-1
> 4: Priorities: Including High +1/-1
> 5: Mandatory Platform and Feature: +1/-1
> 6: Remove Environment field: +1/-1
And when should it get updated?
Currently our KEYS file: that contains the public keys of those that can signed
released binary artifacts; only contains a few of the PMC. My understanding is
that we've avoid updating it because it causes headache for operators in having
to validate the
> I don't see any reason to have any keys in there, except from release
> managers who are signing releases.
Shouldn't any PMC (or committer) should be able to be a release manager?
The release process should be reliable and reproducible enough to be safe for
rotating release managers
> But I'd like to see a serious investigation of the options -- feature set,
> maturity, maintainer availability, etc -- before making a decision. This
> will take some time, but this is a place where "measure twice, cut once"
> seems like the right approach.
I dislike the idea
> I am hoping all the folks who are saying we should not vote will drive the
> other thread. Also note that there is consensus about doing a side car but
> no consensus on which approach to take. I hope not deciding which approach
> is not a poison pill for side car!!
Call me pedantic, but I
> @Mick, thanks for your reply re: publishing snapshots/nightlies. In
> terms of what’s needed to configure these, would it be automation around
> building release artifacts, publishing jars to the Maven snapshots repo, …
Maven artefacts are deployed to the ASF snapshot repository in
> Of course, if we remove Priority from the Bug type, I agree with others
> that the top level priority ceases to mean anything, and there probably
> shouldn’t be one.
Benedict, another idea, and this might be for down the road, is to have
"Severity" or bug types and "Impact" on non-bug
> I propose the following artifacts for release as 2.1.21.
+1 for this release of 2.1.21
- we don't really need the checksums on gpg signature files. (Previously
releases are also doing this.) I believe they can just be manually deleted from
the staging nexus repository.
> I am netbeans user and will be checking NetBeans support. Actually NetBeans
> supports maven natively and any proper maven project should be able to be
> built on netbeans without any modifications.
Thanks SZ !
Note Cassandra is (primarily) ant based. The project file in that ticket is
Cassandra currently has project support for IntelliJ and Eclipse, but not
If there is anyone who uses netbeans (even occasionally) and could help test
the project support proposed in
it would be really appreciated :-)
Mail list logo