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
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
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
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
> 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
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
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
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
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
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
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
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
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
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,
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
15 matches
Mail list logo
