Re: Implicit Casts for Arithmetic Operators

I'm not saying "let's not do this no matter what and ever fix technical debt", nor am I fearing decision. But I *do* think decisions, technical ones at least, should be fact and data driven. And I'm not even sure why we're talking of having a vote here. The Apache Way is *not* meant to be primaril

Re: Implicit Casts for Arithmetic Operators

We’re not presently voting*; we’re only discussing, whether we should base our behaviour on a widely agreed upon standard. I think perhaps the nub of our disagreement is that, in my view, this is the only relevant fact to decide. There is no data to base this decision upon. It’s axiomatic, or

Re: Implicit Casts for Arithmetic Operators

I would also like to see an analysis of what being ANSI SQL 92 compliant means in term of change of behavior (for arithmetics and *any features we have already released*). Simply because without it, I find the decision pretty hard to make. On Thu, Nov 22, 2018 at 11:51 AM Benedict Elliott Smith w

Re: Implicit Casts for Arithmetic Operators

As I say, for me this is explicitly unhelpful, so I have no intention of producing it (though, of course, I cannot prevent you from producing it) For me, the correct approach is to decide where we should be, and then figure out how to get there. Where we are has no bearing on where we should be

Re: Implicit Casts for Arithmetic Operators

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 PM Benedict Elliott Smith wrote: > As I say, for me this is explicitly unhelpful, so I have no intention

Re: Implicit Casts for Arithmetic Operators

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 PM Benedict Elliott Smith

Re: Implicit Casts for Arithmetic Operators

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. > > > On 22 Nov 2018, at 11:32, Benjamin Lerer > wrote: > > > > Then I would be interested in knowing `where we should be`. If the an

Re: Implicit Casts for Arithmetic Operators

Well, to expand my glib statement, standards exist for at least two reasons that I endorse in this case: 1) They are well thought out, with a great deal more consideration than we have time to give to a problem 2) They are widely implemented, understood and used. So our users and developers ha

Re: Implicit Casts for Arithmetic Operators

On Thu, Nov 22, 2018 at 11:51 AM Benedict Elliott Smith wrote: > We’re not presently voting*; we’re only discussing, whether we should base > our behaviour on a widely agreed upon standard. > Well, you *explicitely* asked if people though we should do a vote, and I responded to that part. Let's

Re: Implicit Casts for Arithmetic Operators

This is why I said the decision is ideological. We fundamentally disagree with each other, on points of principle. This also feels like it’s becoming antagonistic, perhaps through misinterpreting each other, which was far from my intent. So I will limit my reply to the only point of interpret

Re: Request to review feature-freeze proposed tickets

> 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 per

Re: Request to review feature-freeze proposed tickets

Strong +1 on prioritizing community engagement 1st and caution second, though still prioritizing it. I think the right metric for us to calibrate around is that "disrupt in-flight testing cycles", i.e. if changes cause significant rework for people that have already begun testing 4.0, probably ok t

Re: JIRA Reports in Confluence

Thanks for sorting out components across all these tickets. I really like the idea of having predefined reports. Looking at how tickets are grouped between 4.0, 4.0.x and 4.x, we should probably do some cleanup for the "fix version" attribute as well. We use to set a ultimate version once a patch

Re: Implicit Casts for Arithmetic Operators

This was a terribly unclear email, sorry. I was just trying to find new and interesting ways to say the same thing (that we should form our goal state from first principles only). Anyway, I think we’ve been arguing very unnecessarily about this ideological point, given that I’ve already sugges

Re: Request to review feature-freeze proposed tickets

We already should be taking correctness and perf changes and I am +1 on taking operational tickets. Agree with Josh that the only exception will be if it causes disruption in testing. I think as a project we should be more open to operational issues as having a fork is not ideal. Regarding ti