Re: Jira Suggestion

2019-05-15 Thread Benedict Elliott Smith
; understood what you were saying, and then bounced down the thread; that's > completely on me and in no way a phrasing error on your part. > > You are 100% correct and are supporting my (apparently multiple) bad > habits. +1 again! > > On Wed, May 15, 2019 at 9:19 AM Benedict E

Re: Jira Suggestion

2019-05-15 Thread Benedict Elliott Smith
> > On Wed, May 15, 2019 at 3:39 AM Sam Tunnicliffe wrote: > >> +1 >> >>> On 14 May 2019, at 20:10, Benedict Elliott Smith >> wrote: >>> >>> It will be possible to insert n/a. It will simply be a text field - >> Jira doesn’t know

Re: Jira Suggestion

2019-05-14 Thread Benedict Elliott Smith
gt; >> 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

Jira Suggestion

2019-05-14 Thread Benedict Elliott Smith
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 perhaps we should codify it instead, while we have the chance? It would also make it easier to find.

Re: Multi-column relations not allowed on partition key/s

2019-04-16 Thread Benedict Elliott Smith
Hi Abhishek, Sorry for the slow response. I would assume the main reason is simply that nobody has implemented the functionality. However, there might be some ideological opposition as well. This query is impossible to implement as efficiently on the server as it is on the client. It

Re: TLP tools for stress testing and building test clusters in AWS

2019-04-16 Thread Benedict Elliott Smith
ld be your evening, could work? >>>>> >>>>> I can set up a Zoom conference to get everyone acquainted. We can >>>>> record and post it for any who can't make it. >>>>> >>>>> I'm thinking Tuesday, Wednesday, or Thursday morning

Jira Updates

2019-04-16 Thread Benedict Elliott Smith
Some exciting news from the Jira changes (maybe). We’re done! We’ve even achieved the stretch goals. Does anyone have any further suggestions from the new workflow, after having tried it out for a bit? Speak up while we have the easy capability to make changes! - Somebody has proposed

Re: Jira: Author Field

2019-04-15 Thread Benedict Elliott Smith
; for after-the-fact research to determine who wrote a thing to reach out >> to >>> them for context? If the latter, does a change in JIRA metadata give us >>> more context than good git commit message hygiene (i.e. list all authors >> on >>> commit msg)? >

Re: Stabilising Internode Messaging in 4.0

2019-04-12 Thread Benedict Elliott Smith
d others have worked for). > Everything we want to do: better testing, better review, better code, is > made easier with better design review, better discussion, and more > digestible patches among many of the other things suggested in this thread. > > Jordan > > On Fri, Apr 12,

Re: Stabilising Internode Messaging in 4.0

2019-04-12 Thread Benedict Elliott Smith
I would once again exhort everyone making these kinds of comment to actually read the code, and to comment on Jira. Preferably with a justification by reference to the code for how or why it would improve the patch. As far as a design document is concerned, it’s very unclear what is being

Re: TLP tools for stress testing and building test clusters in AWS

2019-04-12 Thread Benedict Elliott Smith
+1 I’m also just as excited to see some standardised workloads and test bed. At the moment we’re benefiting from some large contributors doing their own proprietary performance testing, which is super valuable and something we’ve lacked before. But I’m also keen to see some more

Re: Stabilising Internode Messaging in 4.0

2019-04-12 Thread Benedict Elliott Smith
I don’t have a lot to add to Josh’s contribution, except that I’d like to really hammer home that many people were a party to 8099, and as a project we learned a great deal from the experience. It’s a very complex topic, that does not lend itself to simple comparisons, but I think anyone who

Re: Stabilising Internode Messaging in 4.0

2019-04-10 Thread Benedict Elliott Smith
Appreciate everyone's input. It sounds like there's broad agreement that the fixes need to make it into 4.0, which I'm really pleased to see. The question seems to be moving towards scope and timing. TL;DR: This patch is probably the most efficient route to a stable 4.0. The patch is already

Re: Jira: Author Field

2019-04-08 Thread Benedict Elliott Smith
st curious. > > > On Mon, Apr 8, 2019 at 8:55 AM Benedict Elliott Smith > wrote: > >> A couple of people have recently raised the possibility of an Author field >> in JIRA, that permits multiple authors (much like we now support multiple >> reviewers). >> >

Jira: Author Field

2019-04-08 Thread Benedict Elliott Smith
A couple of people have recently raised the possibility of an Author field in JIRA, that permits multiple authors (much like we now support multiple reviewers). Unfortunately this can never be quite as clean as Reviewers, as Assignee is a core Jira field and cannot be replaced entirely by

Re: [jira] [Updated] (CASSANDRA-14096) Cassandra 3.11.1 Repair Causes Out of Memory

2019-03-19 Thread Benedict Elliott Smith
but they did not. > On 19 Mar 2019, at 13:45, Joshua McKenzie wrote: > > I don't recall a vote about anonymous users having transition rights. This > topic irritates me enough that I'm pretty sure I'd go full-on campaign mode > against it. :) > > On Tue, Mar 19, 2019 at 9:44 AM B

Re: [jira] [Updated] (CASSANDRA-14096) Cassandra 3.11.1 Repair Causes Out of Memory

2019-03-19 Thread Benedict Elliott Smith
Hmm. Actually, did we? I’m conflating anonymous with logged-in. > On 19 Mar 2019, at 13:43, Benedict Elliott Smith wrote: > > We can, but we will need to arrange another vote, since we explicitly > discussed this and voted in favour of lifting any limitation on anonymous > u

Re: [jira] [Updated] (CASSANDRA-14096) Cassandra 3.11.1 Repair Causes Out of Memory

2019-03-19 Thread Benedict Elliott Smith
We can, but we will need to arrange another vote, since we explicitly discussed this and voted in favour of lifting any limitation on anonymous users (FWIW, I remain in favour of limiting anonymous users) > On 19 Mar 2019, at 13:35, Joshua McKenzie wrote: > >

Jira Workflow Changes

2019-03-12 Thread Benedict Elliott Smith
The new workflow is now live on Jira. Please let me know ASAP of any bugs or issues you find with it. I had to replicate the changes manually, and I may well have missed something. > On 23 Jan 2019, at 14:12, Benedict Elliott Smith wrote: > > Hi, > > The workflow changes

Re: Related to large partition and row out of order

2019-02-12 Thread Benedict Elliott Smith
This sounds like something you should report upstream as a bug to DataStax. I’m unaware of any bugs in Cassandra mainline that cause this behaviour, but if you can reproduce the creation of this partitions in 3.11.2, we can help to diagnose the cause. But without source code it would be a

Re: [VOTE] Release Apache Cassandra 2.1.21

2019-02-06 Thread Benedict Elliott Smith
+1, and also see no point in EOL; if we have failed to back port something important, we should rectify it. > On 6 Feb 2019, at 05:09, Jeff Jirsa wrote: > > +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

Re: [VOTE] Release Apache Cassandra 2.2.14

2019-02-06 Thread Benedict Elliott Smith
+1 > On 6 Feb 2019, at 05:09, Jeff Jirsa wrote: > > +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: >> >>

Re: [VOTE] Release Apache Cassandra 3.0.18

2019-02-06 Thread Benedict Elliott Smith
+1 > On 6 Feb 2019, at 08:01, Tommy Stendahl wrote: > > +1 (non-binding) > > /Tommy > > On lör, 2019-02-02 at 18:32 -0600, Michael Shuler wrote: > > I propose the following artifacts for release as 3.0.18. > > sha1: edd52cef50a6242609a20d0d84c8eb74c580035e > Git: >

Re: [VOTE] Release Apache Cassandra 3.11.4

2019-02-06 Thread Benedict Elliott Smith
+1 > On 6 Feb 2019, at 08:01, Tommy Stendahl wrote: > > +1 (non-binding) > > /Tommy > > On lör, 2019-02-02 at 18:31 -0600, Michael Shuler wrote: > > I propose the following artifacts for release as 3.11.4. > > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193 > Git: >

Re: [VOTE] Release Apache Cassandra 3.0.18

2019-02-02 Thread Benedict Elliott Smith
CASSANDRA-14812 should probably land in this release, given that it is a critical bug, has been patch available for a while, and is relatively simple. That said, we are sorely due a release. But if we go ahead without it, we should follow up soon after. > On 3 Feb 2019, at 00:32, Michael

Jira Workflow Changes Beta

2019-01-23 Thread Benedict Elliott Smith
Hi, The workflow changes are largely up to try out here: https://issues-test.apache.org/jira/browse/CASSANDRA I’d appreciate some beta testing, to make sure I haven’t made any errors in the transitions (I’ve done some, but a few more would be useful). There were a lot of changes, and Jira is

Re: Regarding CASSANDRA-14227

2019-01-11 Thread Benedict Elliott Smith
The project is primarily pushing towards a higher quality 4.0 release, so I am unaware of anybody considering this bug. There’s a strong argument to be made for this to be fixed in 4.0, since it ideally requires a major version bump. I can’t promise anybody will prioritise this over their

[JIRA Epic] Removing Contributor Role

2019-01-09 Thread Benedict Elliott Smith
In discussing this aspect of the change with ASF Infra, Gavin McDonald asked for a reconsideration. Firstly, he was concerned about Jira struggling under the load of auto-populating 12 user names. He suggested waiting until they have migrated users to LDAP later this year. Given Jira’s

Component Migration

2019-01-03 Thread Benedict Elliott Smith
Following the vote for JIRA workflow changes, I have introduced the new Components and migrated any that were relatively easy*. I have retained the old Component values with the prefix Legacy/. I have also introduced the proposed Feature field into Component for now, until we can establish if

Re: [VOTE] Change Jira Workflow

2019-01-02 Thread Benedict Elliott Smith
t; On Mon, Dec 17, 2018, at 10:19 AM, Benedict Elliott Smith wrote: >>> I propose these changes >>> < >> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals>* >> >>> to the Jira Workflow for the project. The vote will be op

[VOTE] Change Jira Workflow

2018-12-17 Thread Benedict Elliott Smith
I propose these changes * to the Jira Workflow for the project. The vote will be open for 72 hours**. I am, of course, +1. * With the addendum of the mailing list discussion

Re: Revisit the proposal to use github PR

2018-12-14 Thread Benedict Elliott Smith
omments and discussion are persisted in Apache >> Jira as >>>>> work log so it can be audited if desired. However, committers usually >>>>> squash and commit the changes once the PR is approved. We don't use >> the >>>>> merge feature in github. I

Re: cassandra-stress HexStrings generator

2018-12-13 Thread Benedict Elliott Smith
I’m honestly not sure. The code has changed since I last worked on it, which was years ago. I suspect the profile mode has entirely supplanted the prior modes, and that these older modes supported the HexStrings generator. Perhaps somebody else can help answer this question. > On 13 Dec

Re: cassandra-stress HexStrings generator

2018-12-12 Thread Benedict Elliott Smith
Yes, I’m pretty sure you understood correctly (I wrote most of this, but it’s been a long time so I cannot remember much for certain). It should be implemented like the Strings generator. It looks like both HexStrings and HexBytes are incorrect, and have been for a long time. > On 12 Dec

Re: Revisit the proposal to use github PR

2018-12-12 Thread Benedict Elliott Smith
Perhaps somebody could summarise the tradeoffs? I’m a little concerned about how it would work for our multi-branch workflow. Would we open multiple PRs? Could we easily link with external CircleCI? It occurs to me, in JIRA proposal mode, that an extra required field for a permalink to

Re: JIRA Workflow Proposals

2018-12-11 Thread Benedict Elliott Smith
>> type really) >> -- >> Sylvain >> >> >> On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko >> wrote: >> >>> 1. C, D, A, B, E >>> 2. B, C, A >>> 3. A >>> 4. Meh >>> >>>> On 11 Dec 2018

Re: JIRA Workflow Proposals

2018-12-11 Thread Benedict Elliott Smith
priority or issue > type really) > -- > Sylvain > > > On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko > wrote: > >> 1. C, D, A, B, E >> 2. B, C, A >> 3. A >> 4. Meh >> >>> On 11 Dec 2018, at 16:28, Benedict Elliott Smith >&

Re: JIRA Workflow Proposals

2018-12-11 Thread Benedict Elliott Smith
>> Limiting edits to certain fields turns people off. Something I want to very >> much avoid if we can. >> >> Dinesh >> >>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan >>> wrote: >>> >>> On Tue, 11 Dec 2018 at 10:51, Bened

Re: JIRA Workflow Proposals

2018-12-11 Thread Benedict Elliott Smith
10, 2018, at 6:14 PM, Murukesh Mohanan >> wrote: >> >> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith >> wrote: >>> >>>> On 10 Dec 2018, at 16:21, Ariel Weisberg wrote: >>>> >>>> Hi, >>>> >>&

Re: JIRA Workflow Proposals

2018-12-10 Thread Benedict Elliott Smith
ree to share it. > Not voting yet just because I'm not sure on some. > > Ariel > > On Mon, Dec 10, 2018, at 7:43 AM, Benedict Elliott Smith wrote: >> New questions. This is the last round, before I call a proper vote on >> the modified proposal (so we can take a m

Re: JIRA Workflow Proposals

2018-12-10 Thread Benedict Elliott Smith
ate it myself usually I put it in the description or the > subject without thinking. > > It seems like the purpose of a field is to make it indexable and possibly > structured. How often do we search or require structure on this field? > > Ariel > > On Tue, Dec 4,

Re: JIRA Workflow Proposals

2018-12-10 Thread Benedict Elliott Smith
The “Impact” field idea sounds like a good potential follow-up discussion. I’d prefer not to complicate this process when we’re seemingly nearing consensus, particularly as I’m not personally sure what form such a field would take. But it would be a relatively small modification, if you want

Re: JIRA Workflow Proposals

2018-12-07 Thread Benedict Elliott Smith
re impact and platform. It's platform I think is less useful? I > am +1 on feature impacts as we have impact on things like CCM and drivers > that we need to keep track of and I do forget them at times. > > Ariel > > On Fri, Dec 7, 2018, at 1:17 PM, Benedict Elliott Smith wrote:

Re: JIRA Workflow Proposals

2018-12-07 Thread Benedict Elliott Smith
mandatory. Here we’re trying to gauge an ideal end state - some things may need revisiting if JIRA does not play ball, though that should not affect many items. > > Ariel > > On Tue, Dec 4, 2018, at 2:12 PM, Benedict Elliott Smith wrote: >> Ok, so after an initial flurry every

Re: JIRA Workflow Proposals

2018-12-06 Thread Benedict Elliott Smith
Dec 2018, at 08:16, Sylvain Lebresne wrote: >> >> Not much to add really, but just to close the loop, responses inline. >> >> On Wed, Dec 5, 2018 at 11:58 AM Benedict Elliott Smith > <mailto:bened...@apache.org>> >> wrote: >> >>> Thanks for t

Re: JIRA Workflow Proposals

2018-12-06 Thread Benedict Elliott Smith
> >> Summary: >> >> 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 >> > > 1:

Re: JIRA Workflow Proposals

2018-12-05 Thread Benedict Elliott Smith
ave an opinion? > As for workflow changes, I don't have a real opinion on that yet and > like to give this some more thoughts. But the suggested review status > changes are something I'd definitely like to see happening. > > > On 04.12.18 20:12, Benedict Elliott Smith wrote:

Re: JIRA Workflow Proposals

2018-12-05 Thread Benedict Elliott Smith
ests that come in that have no realistic timeline for being addressed. > > And with that, my poll results: > 1:A > 2:+1 > 3:+1 > 4:Don't mind > 5:Don't mind > -- > Sylvain > > > On Tue, Dec 4, 2018 at 8:12 PM Benedict Elliott Smith > wrote: > >

Re: JIRA Workflow Proposals

2018-12-04 Thread Benedict Elliott Smith
Sorry, 4. Is inconsistent. First instance should be. > - 4. Priorities: Keep ‘High' priority > On 4 Dec 2018, at 19:12, Benedict Elliott Smith wrote: > > Ok, so after an initial flurry everyone has lost interest :) > > I think we should take a quick poll (not a vote), on

Re: JIRA Workflow Proposals

2018-12-04 Thread Benedict Elliott Smith
oposal. "Workflow > and bug tracker hygiene” can be a thankless endeavor; I want to make sure > this one’s not. Thank you both! > > If we’re nearing consensus on “keeping labels, and considering them for > promotion to components periodically,” are there other items we nee

Re: JIRA Workflow Proposals

2018-11-26 Thread Benedict Elliott Smith
:02, Benedict Elliott Smith wrote: > > Do we maintain a list of prior rejects? Revisit any that have increased in > usage since last? > > Probably we’re bike shedding this one thing too closely. I would be happy > with removing it, periodically cleaning it, or leavi

Re: JIRA Workflow Proposals

2018-11-26 Thread Benedict Elliott Smith
ncerns are addressed by the new Triage state. >>>> The idea is for users to create a ticket without any field requirements. >>>> Contributors should liaise with the user to understand the problem, and >>>> transition it to Open. >>> >>> Shit,

Re: JIRA Workflow Proposals

2018-11-26 Thread Benedict Elliott Smith
users to create a ticket without any field requirements. >> Contributors should liaise with the user to understand the problem, and >> transition it to Open. > > Shit, my bad, totally missed / didn't grok that. That makes a lot more > sense. > > On Mon, Nov 26, 2018

Re: JIRA Workflow Proposals

2018-11-26 Thread Benedict Elliott Smith
trying to make it easier for people that are paid >> FT to work on C*, are we trying to make things easier for *users* of C*, >> both, neither? Who are we targeting here w/these project changes and what >> of their issues / problems are we trying to improve? >> >&g

Re: JIRA Workflow Proposals

2018-11-26 Thread Benedict Elliott Smith
easure release quality over time and >>>> identify when Cassandra is ready for (or due a) release. >>>> >>>> The proposal in its current form makes certain strong inroads in all of >>>> those 4 metrics, but I think the major thing missing is the U

Re: JIRA Workflow Proposals

2018-11-26 Thread Benedict Elliott Smith
ght", though I'd argue >>> against it being *easy*) >>> 2. Asking from the users what they can provide about their experience >>> and issues and no more >>> >>> Philosophically, are we trying to make it easier for people that are paid >>&

JIRA Workflow Proposals

2018-11-26 Thread Benedict Elliott Smith
We’ve concluded our efforts to produce a proposal for changes to the JIRA workflow, and they can be found here: https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals I hope there will be

Re: Implicit Casts for Arithmetic Operators

2018-11-23 Thread Benedict Elliott Smith
uld _all_ be factored in. > > Currently, we have very little information on how bad 3) and 4) are. So my > current personal opinion is that 1) does justify looking into this much > more closely, and that if 3) and 4) aren't too bad, that's a good deal for > the > project. But in li

Re: Implicit Casts for Arithmetic Operators

2018-11-22 Thread Benedict Elliott Smith
suggested a toggle to permit users to continue with present-day semantics should they choose. Surely this resolves your concerns, unless you think this is intractable? > On 22 Nov 2018, at 12:13, Benedict Elliott Smith wrote: > > This is why I said the decision is ideological. We fund

Re: Request to review feature-freeze proposed tickets

2018-11-22 Thread Benedict Elliott Smith
> I assume it's obvious to everyone that this should be taken on a > case-by-case basis. There's at least 2 that were in that list (one of which > Marcus bumped off PA) that are potentially big and hairy changes that would > disrupt in-flight testing cycles. Agreed. I’d prefer we aim to be as

Re: Implicit Casts for Arithmetic Operators

2018-11-22 Thread Benedict Elliott Smith
>>> voting first and doing the analysis 2nd. >>> >>> -- >>> Sylvain >>> >>> >>> On Thu, Nov 22, 2018 at 1:25 AM Jonathan Haddad >> wrote: >>> >>>> I can’t agree more. We should be able to make changes in a m

Re: Implicit Casts for Arithmetic Operators

2018-11-22 Thread Benedict Elliott Smith
have a common point of reference. > On 22 Nov 2018, at 11:42, Benjamin Lerer wrote: > > Sorry, following a standard for the sake of following a standard does not > make sense to me. > > On Thu, Nov 22, 2018 at 12:33 PM Benedict Elliott Smith > wrote: > >> Yes. &g

Re: Implicit Casts for Arithmetic Operators

2018-11-22 Thread Benedict Elliott Smith
Yes. > On 22 Nov 2018, at 11:32, Benjamin Lerer wrote: > > Then I would be interested in knowing `where we should be`. If the answer > is `ANSI SQL92` then my question is: Why? Simply for the sake of following > a standard? > > > On Thu, Nov 22, 2018 at 12:19 P

Re: Implicit Casts for Arithmetic Operators

2018-11-22 Thread Benedict Elliott Smith
find the decision pretty hard to make. > > On Thu, Nov 22, 2018 at 11:51 AM Benedict Elliott Smith <mailto:bened...@apache.org>> > wrote: > >> We’re not presently voting*; we’re only discussing, whether we should base >> our behaviour on a widely agreed u

Re: Implicit Casts for Arithmetic Operators

2018-11-22 Thread Benedict Elliott Smith
to make changes in a manner that >> improves the DB In the long term, rather than live with the technical debt >> of arbitrary decisions made by a handful of people. >> >> I also agree that putting a knob in place to let people migrate over is a >> reasonable decision. >

Re: Implicit Casts for Arithmetic Operators

2018-11-21 Thread Benedict Elliott Smith
it. > On 21 Nov 2018, at 21:08, Sylvain Lebresne wrote: > > On Tue, Nov 20, 2018 at 5:02 PM Benedict Elliott Smith > wrote: > >> FWIW, my meaning of arithmetic in this context extends to any features we >> have already released (such as aggregates, and perhaps

Re: Implicit Casts for Arithmetic Operators

2018-11-20 Thread Benedict Elliott Smith
This is a public API so we will be much better off if we get it right the > first time. > > Ariel > >> On Nov 16, 2018, at 10:36 AM, Jonathan Haddad wrote: >> >> Sounds good to me. >> >> On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliot

Re: Implicit Casts for Arithmetic Operators

2018-11-16 Thread Benedict Elliott Smith
low if we detect we need more precision. > > Ariel > On Fri, Oct 12, 2018, at 12:45 PM, Benedict Elliott Smith wrote: >> If it’s in the SQL spec, I’m fairly convinced. Thanks for digging this >> out (and Mike for getting some empirical examples). >> >> We still have to

Re: Proposed changes to CircleCI testing workflow

2018-10-26 Thread Benedict Elliott Smith
Just want to say +1, and thanks for taking the time to do this. This all sounds great. (And completely supersedes what I hoped to achieve with CASSANDRA-14648) > On 26 Oct 2018, at 15:49, Stefan Podkowinski wrote: > > I'd like to give you a quick update on the work that has been done >

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-24 Thread Benedict Elliott Smith
is old, I've learned that it pays to > be very, very cautious. > > On Tue, Oct 23, 2018 at 3:33 PM Jeff Jirsa wrote: > >> My objection (-0.5) is based on freeze not in code complexity >> >> >> >> -- >> Jeff Jirsa >> >> >>> O

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-23 Thread Benedict Elliott Smith
.5 respectively. > > Ariel > > On Tue, Oct 23, 2018, at 11:50 AM, Benedict Elliott Smith wrote: >> I’m +1 change of default. I think Jeff was -1 on that though. >> >> >>> On 23 Oct 2018, at 16:46, Ariel Weisberg wrote: >>> >>> Hi, >

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-23 Thread Benedict Elliott Smith
I’m +1 change of default. I think Jeff was -1 on that though. > On 23 Oct 2018, at 16:46, Ariel Weisberg wrote: > > Hi, > > To summarize who we have heard from so far > > WRT to changing just the default: > > +1: > Jon Haddadd > Ben Bromhead > Alain Rodriguez > Sankalp Kohli (not explicit)

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Benedict Elliott Smith
Shall we move this discussion to a separate thread? I agree it needs to be had, but this will definitely derail this discussion. To respond only to the relevant portion for this thread: > changing years-old defaults I don’t see how age is relevant? This isn’t some ‘battle hardened’ feature

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Benedict Elliott Smith
a lot. It's a bit >>> suspicious really when you look at the ratio of performance to block size >>> being close to 1:1. I couldn't spot a bug in the benchmark though. >>> >>> Compression ratios with LZ4 fast for the text of Alice in Wonderland was: >>> >&

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-18 Thread Benedict Elliott Smith
FWIW, I’m not -0, just think that long after the freeze date a change like this needs a strong mandate from the community. I think the change is a good one. > On 17 Oct 2018, at 22:09, Ariel Weisberg wrote: > > Hi, > > It's really not appreciably slower compared to the decompression we

Re: Implicit Casts for Arithmetic Operators

2018-10-12 Thread Benedict Elliott Smith
double. This would be something the spec allows. > > Definitely if we can make overflow not occur we should and the spec allows > that. We should also not return different types for the same operand types > just to work around overflow if we detect we need more precision. &

Re: Implicit Casts for Arithmetic Operators

2018-10-12 Thread Benedict Elliott Smith
ound(1) returns double 3 >> >> So as we're going to have silly values in any case, why pretend something >> else? Also, exact calculations are slow if we crunch large amount of >> numbers. I guess I slightly deviated towards Postgres' implemention in this >> case, but

Re: Implicit Casts for Arithmetic Operators

2018-10-12 Thread Benedict Elliott Smith
As far as I can tell we reached a relatively strong consensus that we should implement lossless casts by default? Does anyone have anything more to add? Looking at the emails, everyone who participated and expressed a preference was in favour of the “Postgres approach” of upcasting to decimal

Re: Implicit Casts for Arithmetic Operators

2018-10-02 Thread Benedict Elliott Smith
f results sets actually sounds worse if we want > to also improve aggregrations. Many applications won't notice if the client > library abstracts that away, but I think there are still cases where people > would notice the type changing. > > Ariel > >> On Tue, Oct 2, 2018,

Re: Implicit Casts for Arithmetic Operators

2018-10-02 Thread Benedict Elliott Smith
p#L2213 > <https://github.com/VoltDB/voltdb/blob/master/src/ee/common/NValue.hpp#L2213> > https://github.com/VoltDB/voltdb/blob/master/src/ee/common/NValue.hpp#L3764 > <https://github.com/VoltDB/voltdb/blob/master/src/ee/common/NValue.hpp#L3764> > > Ariel > >

Implicit Casts for Arithmetic Operators

2018-10-02 Thread Benedict Elliott Smith
CASSANDRA-11935 introduced arithmetic operators, and alongside these came implicit casts for their operands. There is a semantic decision to be made, and I think the project would do well to explicitly raise this kind of question for wider input before release, since the project is bound by

Re: Moving tickets out of 4.0 post freeze

2018-09-25 Thread Benedict Elliott Smith
Do we want to manage more versions than we do now? Why don’t we simply align these things to majors, like we’ve typically tried to anyway? I think it’s anyway better to decide on a strategy and find a versioning scheme that matches it, rather than to look for a strategy that matches our

Re: [DISCUSS] changing default token behavior for 4.0

2018-09-24 Thread Benedict Elliott Smith
This sounds worthy of a bug report! We should at least document any such inadequacy, and come up with a plan to fix it. It would be great if you could file a ticket with a detailed example of the problem. > On 24 Sep 2018, at 14:57, Tom van der Woerdt > wrote: > > Late comment, but I'll

Re: Moving tickets out of 4.0 post freeze

2018-09-24 Thread Benedict Elliott Smith
4.1, I think we > should keep it 4.0.x, in line with 2.2.x, 3.0.x, 3.11.x. And yes our Major>.. versioning of the past never followed semver. > > -Jeremiah > >> On Sep 24, 2018, at 11:45 AM, Benedict Elliott Smith >> wrote: >> >> I’d like to pro

Re: Moving tickets out of 4.0 post freeze

2018-09-24 Thread Benedict Elliott Smith
I’d like to propose we don’t do Semver. Back when we did this before, there wasn’t any clear distinction between a major and a minor release. They were both infrequent, both big, and were treated as majors for EOL'ing support for older releases. This must surely have been confusing for

Re: Measuring Release Quality

2018-09-22 Thread Benedict Elliott Smith
>> – Considering adding a "severity” field to capture the distinction between >> priority and severity. >> ––– >> >> If there’s appetite for spending a little time on this, I’d put effort >> toward it if others are interested; is anyone? >> >>

Re: Measuring Release Quality

2018-09-20 Thread Benedict Elliott Smith
I think it would be great to start getting some high quality info out of JIRA, but I think we need to clean up and standardise how we use it to facilitate this. Take the Component field as an example. This is the current list of options: 4.0 Auth Build Compaction Configuration Core CQL

Re: Side Car New Repo vs not

2018-08-23 Thread Benedict Elliott Smith
+1 also for separate repo > On 24 Aug 2018, at 01:11, Jeff Jirsa wrote: > > +1 for separate repo > > > -- > Jeff Jirsa > > >> On Aug 23, 2018, at 1:00 PM, sankalp kohli wrote: >> >> Separate repo is in a majority so far. Please reply to this thread with >> your responses. >> >> On Tue,

Re: GitHub PR ticket spam

2018-08-06 Thread Benedict Elliott Smith
Also +1 It might perhaps be nice to (just once) have ASF Bot comment that a GitHub discussion has been replicated to the worklog? In the Arrow example, for instance, it isn’t immediately obvious that there are any worklog comments to look at. Or perhaps we should require committers to

Re: GitHub PR ticket spam

2018-07-30 Thread Benedict Elliott Smith
I agree this is a mess. I think we have previously taken the view that JIRA should be the permanent record of discussion, and that as such the git conversation should be duplicated there. However, I think it would be better for JIRA to get a summary of important discussions, by one of the

Re: Testing 4.0 Post-Freeze

2018-07-10 Thread Benedict Elliott Smith
it's > probably just noise now, so I won't respond any further on this > thread. I don't anticipate having a personal need to commit to a > future 5.0 release before 4.0 is out, so it won't impact me > personally. > > On Tue, Jul 10, 2018 at 10:32 AM Benedict Elliott Smith > w

Re: Testing 4.0 Post-Freeze

2018-07-10 Thread Benedict Elliott Smith
That’s a peculiar way of looking at it. Committer status is not an absolute right to autonomy over the codebase. It’s an embodiment of trust that you will follow the community's prevailing rules around commit, and that you’re competent to do so. If the community wants to change those rules

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Benedict Elliott Smith
+1. > On 9 Jul 2018, at 20:17, Mick Semb Wever wrote: > > >> 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

Re: Use of OpOrder in memtable

2018-02-13 Thread Benedict Elliott Smith
; including SSTable read and timestamp comparison etc.) > > -Original Message- > From: Benedict Elliott Smith [mailto:bened...@apache.org] > Sent: Tuesday, February 13, 2018 2:25 PM > To: dev@cassandra.apache.org > Subject: Re: Use of OpOrder in memtable > > If y

Re: Use of OpOrder in memtable

2018-02-13 Thread Benedict Elliott Smith
If you look closely, there can be multiple memtables extant at once. While all "new" writes are routed to the latest memtable, there may still be writes that have begun but not yet completed. The memtable cannot be flushed until any stragglers have completed, and some stragglers *may* still need

Re: Coordinator Write Metrics per CF

2018-02-13 Thread Benedict Elliott Smith
Sorry, I guess I'm tired. I thought this was discussing local write latency. I'm surprised we have that and not coordinator write latency. Please do ignore me, I'm not sure why I got involved! On 13 February 2018 at 21:48, Benedict Elliott Smith <bened...@apache.org> wrote: > For t

Re: Coordinator Write Metrics per CF

2018-02-13 Thread Benedict Elliott Smith
For the record, I'm not certain there *is* a great deal of value in this. The read latency metrics are expected to vary a great deal, since the entire IO subsystem is involved. Writes, however, go straight to a memtable. They only block on IO if we exceed our commit log flush bandwidth for an

Re: Getting partition min/max timestamp

2018-01-14 Thread Benedict Elliott Smith
t for me? > > On 2018-01-14 17:16, Benedict Elliott Smith <bened...@apache.org> wrote: > > (Obviously, not to detract from the points that Jon and Jeremiah make, > i.e. > > that if TTLs or tombstones are involved the metadata we have, or can add, > > is going to be w

Re: Getting partition min/max timestamp

2018-01-14 Thread Benedict Elliott Smith
(Obviously, not to detract from the points that Jon and Jeremiah make, i.e. that if TTLs or tombstones are involved the metadata we have, or can add, is going to be worthless in most cases anyway) On 14 January 2018 at 16:11, Benedict Elliott Smith <bened...@apache.org> wrote: > We alre

Re: Getting partition min/max timestamp

2018-01-14 Thread Benedict Elliott Smith
We already store the minimum timestamp in the EncodingStats of each partition, to support more efficient encoding of atom timestamps. This just isn't exposed beyond UnfilteredRowIterator, though it probably could be. Storing the max alongside would still require justification, though its cost

  1   2   >