Vladimir Sitnikov created CALCITE-2463:
--
Summary: Silence ERROR logs from CalciteException,
SqlValidatorException
Key: CALCITE-2463
URL: https://issues.apache.org/jira/browse/CALCITE-2463
My hope is that we could fix this "once" by adding another component :)
To Francis' point, a standardized solution around this problem in which
we use some other tech (e.g. haproxy) would be directly reusable for an
Avatica client in any language.
I think a very nice contribution would be
First off, thanks for staying engaged with this conversation, Vladimir.
I know this stuff is uncomfortable to talk through.
On 8/10/18 1:34 PM, Vladimir Sitnikov wrote:
Josh>That doesn't mean you can stop CALCITE-2438 from happening meanwhile
Of course I can't.
Ok, good. Just making sure :)
Vladimir Sitnikov created CALCITE-2462:
--
Summary: RexProgramTest: move "rex building" methods to base class
Key: CALCITE-2462
URL: https://issues.apache.org/jira/browse/CALCITE-2462
Project:
Committers, here is something watch out for.
I am reviewing a case (see
https://github.com/apache/calcite/pull/782/commits) where the pull
request (PR) was made by one github user and the git commit is made by
a different github user.
The PR is important to the integrity of the intellectual
Josh>Shutting down and saying "I'm
Josh>not interacting with this more" is equivalent in my eyes to saying
"I'm
Josh>withdrawing my veto".
This is exactly the reason I continue with the discussion even after I say
I do not want to spend time on the issue.
Of course, this thread is a great waste
Totally make sense. The only inconvenience is that every user has to repeat the
same work by setting up the sticky sessions.
-Jiandan
> On Aug 9, 2018, at 1:08 PM, Josh Elser wrote:
>
> The decision of avoiding "routing logic" in the client was that other systems
> can do a better job than
Somehow, my impression was that the Avatica implementation was such that the
states are carried in the request/response so that server does not need to
maintain any specific state for a jdbc session. Just as Julian described.
Obviously I was wrong. Just curious what is the exact states
I’ve sent one or two emails on the subject in the last few months.
But mostly it’s a convention, "a way in which something is usually done”; the
rule is to follow the same style as other commits.
Julian
> On Aug 9, 2018, at 1:42 PM, Vladimir Sitnikov
> wrote:
>
> Julian>Please adhere to
Yep, concur on these points. My understanding on them all.
On 8/10/18 12:33 PM, Julian Hyde wrote:
That’s my understanding as well.
I thought we’d settled this a while ago. (I can’t find a URL to prove it.)
Julian
On Aug 10, 2018, at 7:58 AM, Enrico Olivelli wrote:
I think it is fine to
(I'll come around to your reply to my original, Vladimir. Need lots more
time than I have today to address all of that.)
I want to address one specific point here that I find troubling: A veto
is not something you can levy and then say you're "[checked out]".
There is no "high ground" here.
I agree with most of what Vladimir said. But briefly:
* It isn’t often necessary for the contributor to rebase. The reviewer will ask
for a rebase if it’s really needed.
* If you add a commit after an initial review, it’s really important that you
do not squash (or amend). The reviewer wants to
That’s my understanding as well.
I thought we’d settled this a while ago. (I can’t find a URL to prove it.)
Julian
> On Aug 10, 2018, at 7:58 AM, Enrico Olivelli wrote:
>
> I think it is fine to use JMH, you are not "redistributing" it, it is here
> only to run local benchmarks.
>
> We have
Michael>Unless I'm missing something, this was not something you proposed
on the
Michael>JIRA issue, correct?
Please check [1], [6] and subsequent messages.
Your mileage might vary, yet adding proper assertion messages was exactly
what I asked to do several times ("error messages" is present in
I think it is fine to use JMH, you are not "redistributing" it, it is here
only to run local benchmarks.
We have the same in Apache BookKeeper codebase
just my 2 cents
Enrico
Il giorno ven 10 ago 2018 alle ore 16:56 Michael Mior ha
scritto:
> Perhaps we should just open up a JIRA case on
Perhaps we should just open up a JIRA case on legal for an official ruling.
It does seem like we should try to have ubenchmark excluded from releases.
Unless I'm mistaken, I don't belive it's required.
On Thu, Aug 9, 2018, 4:01 PM Vladimir Sitnikov
wrote:
> There are two questions there:
> 1)
Vladimir,
While I haven't run or even carefully examined the code in question, your
"three line diff" looks compelling given the test results before and after.
Unless I'm missing something, this was not something you proposed on the
JIRA issue, correct? If this were applied on top of the existing
Stamatis>Personally, I always perform rebase followed by a forced push
I was inclined to use that policy in early days, yet I think it should not
be the main way.
Bellow assumes GitHub. If we happen to use Gerrit things might shine with a
different colour.
I suggest the following.
FAQ:
Q: I
IMO, it depends on how extensive the changes are. Eventually we certainly
prefer the rebase and force push approach . However, if the PR is complex
and a lot of changes have been made, it can be helpful to temporarily add a
commitment (which will be squashed later) to help the reviewer see what
Hi,
Contributing to Calcite is quite well documented in the website (
https://calcite.apache.org/develop/#contributing). One minor thing that
might be missing is how to update the pull request when changes are
required by the reviewers.
Personally, I always perform rebase followed by a forced
Josh>3-part veto from [1]. The first cites maintainability/readability of
Josh>unit tests. This feels more subjective than objective, and against the
Josh>spirit of a veto
Josh, are you sure you did check the contents of pull/778 as of 7 Aug 2018
08:00 UTC? (which is the timestamp of [1] comment)
21 matches
Mail list logo
