Hi,
https://github.com/apache/calcite/pull/1625 fixes concurrency issues with
Checkstyle and improves "code style" error messages.
if no-one objects within three days, I'll assume lazy consensus and commit
it.
You can find more info here:
Thank everybody for your participation.
The vote results are:
+1 Vladimir
-0 Michael
-1 Julian (it can not count as a veto because there's no technical
justification)
Unfortunately, the vote is undecided.
Vladimir
Stamatis>I mean that there are a few people who are a bit skeptical with
the change
Stamatis>so it seems that more convincing elements are needed.
There's no way to convince people who do not want to analyze Checkstyle /
build configuration themselves.
Everybody was happy with Maven, and there
I mean that there are a few people who are a bit skeptical with the change
so it seems that more convincing elements are needed.
>From my side, I would like to note that the Checkstyle related problems
that I encountered are reproducible (see CALCITE-3581 [1]).
I cannot yet explain why but with
Stamatis> I still think we can solve this here by discussing a bit more
What do you mean by that?
Stamatis> Actualy, I think that it was stuck every single time that there
was an
error.
No idea. It does not stuck every time, and I have seen a lot of
checkstyle-triggered build failures.
I still think we can solve this here by discussing a bit more; opening new
threads/votes is only going to take more time from all of us.
Today, I noticed that Gradle build was stuck quite a few times while
performing the checkstyleTest.
Actually, I think that it was stuck every single time that
>I was referring to your own comment on the PR which indicated
>two missing checks
Exactly. You don't seem to evaluate the importance (and use frequency) of
the dropped checks.
In any case, you don't want to express your opinion as +1 or -1. That is
fine.
The vote is open till 2019-12-09
I'm not sure why you assume I don't know what checks are there. In any
case, I was referring to your own comment on the PR which indicated
two missing checks. Compiling the plugin before running checkstyle
doesn't sound too painful, but I'm not really familiar with
Gradle/Kotlin.
--
Michael Mior
Michael> -0 because I haven't found checkstyle violations
Michael> and I don't like the idea of losing checks which are currently in
Michael> place
Would you please re-evaluate? I seems like you did not know which checks
are there and which are not.
To my best knowledge, the only missing check
Michael>wee could always pull the relevan code into Calcite
Do you realize Checkstyle does not support source-code based plugins?
It requires jar files. It would be non-trivial to build a custom checkstyle
plugin in the beginning of Calcite build and use it later in the same build.
Danny> it normalize the file end pretty well(avoid all kinds of file end)
I just realized there's JIRA which answers it:
https://issues.apache.org/jira/browse/CALCITE-490
One can't avoid 'file end'. The file has to end with something, and the use
of '// End' does not avoid file end.
'// End
Project-specific rules are missing, thus general rules apply:
https://www.apache.org/foundation/voting.html#votes-on-code-modification ,
https://www.apache.org/foundation/voting.html
It says:
> In this scenario, a negative vote constitutes a veto
I’m not voting, I just want to say something to this HydromaticFileSetCheck
>* HydromaticFileSetCheck produces hard to understand messages. I guess many
of you have faced "Open parentheses exceed closes by 2 or more
[HydromaticFileSet]" issue, and I guess you it took you a lot to understand
what
Vladimir created the confusion by starting a vote on a commit, and without
specifying the rules of the vote (unanimous, majority, lazy consensus). Then
later on he referred to it as a discussion.
Assuming that this was a discussion, my “-1” meant “I’m generally against this
idea”.
It’s
I'll leave Julian to clarify whether or not the -1 was intended to be
a veto, but as you noted, Julian expressed some concern in the PR and
the associated JIRA. If we are voting, I'm currently -0 because I
haven't found checkstyle violations to be significant problem for me
and I don't like the
I'm not following many Apache projects but in those that I do I don't see
votes for code modifications very often. There is always some tension
whenever somebody calls for a vote so personally I would prefer if could go
without. I'm sure Vladimir did it with good intentions so that the
discussion
Michael>I didn't interpret Jullian's -1 as a veto
> https://www.apache.org/foundation/voting.html#Veto
> A code-modification proposal may be stopped dead in its tracks by a -1
vote by a qualified voter.
> This constitutes a veto, and it cannot be overruled nor overridden by
anyone.
> Vetos stand
I didn't interpret Jullian's -1 as a veto. I agree that we generally
don't need to vote on code changes. I don't believe we ever voted on
the Gradle migration and IMO that was a much moree significant change.
--
Michael Mior
mm...@apache.org
Le mer. 4 déc. 2019 à 14:28, Vladimir Sitnikov
a
Julian>-1
I see your pain, however, please remember:
ASF> https://www.apache.org/foundation/voting.html#Veto
ASF> A veto without a justification is invalid and has no weight
The PR is a clear improvement, and we can always make it better (e.g. by
committing more code).
We even can roll it back
It’s unusual to vote on a code change. We could just have a discussion, and
reach consensus about whether the PR is a net benefit.
-1
> On Dec 4, 2019, at 2:30 AM, Vladimir Sitnikov
> wrote:
>
> Hi,
>
> I suggest we drop HydromaticFileSetCheck from the Checkstyle configuration.
> It was a
Hi,
I suggest we drop HydromaticFileSetCheck from the Checkstyle configuration.
It was a great journey (thanks Julian for HydromaticFileSetCheck), however,
lots of tools have improved since then, so we could upgrade to the better
tooling now.
[ ] +1, drop HydromaticFileSetCheck, just do it
[ ]
21 matches
Mail list logo
