When we discussed last time, all of us were in favour and wanted to
have documentation as part of our website per version, but we realised
that isn't very much chasable considering the number of volunteers we
have, so we decided to go with improving the existing wiki pages & add
new additions to th
+1
I think most of the devs use IntelliJ, where no other plugin needed to have
a Code Style. It can even import Eclipse formatting file.
Regards,
RZ
On Mon, Jan 8, 2024 at 10:22 AM Stamatis Zampetakis
wrote:
> +1 for enforcing style on new code. It will definitely save us from
> additional re
Hi Zsolt,
The current hive website is built with hugo, so +1 from me :)
We do have a few doc pages written in hugo, example :
https://hive.apache.org/developement/quickstart/
To add a new page we will need to add a new markdown file in the correct
location in the hive-site repo and hugo will re
Hey Zsolt,
There have been a few discussions in the past about moving the
documentation from the wiki to the website and from what I recall
people were more or less in favor of moving towards this direction.
The main thing missing is volunteers that are willing to take on this
migration step.
Per
+1 for enforcing style on new code. It will definitely save us from
additional review cycles.
Although I like checkstyle I tend to prefer tools that can
automatically apply and fix style violations such as spotless [1].
It seems that the spotless plugin can be configured to enforce
formatting gra
I think giving a warning is something that nobody will check. It could only
make sense if it is formatted in a way that it cannot be overseen. In every
other case, it is just ignored. And also, we are already full of warnings
so I'm afraid it can just hide in the noise.
Sorry, I don't know how it w
+1, to have a checkstyle build. I am strongly against doing that big
refactor to make just checkstyle happy, such a refactor will make
backports to Hive lower branches tough and the life of folks
maintaining downstream forks quite painful.
We should enforce same kind of stuff like in Tez/Hadoop, w
thanks for the responses so far!
I'm a bit against the one-time huge refactor commit as we don't need that
(but I can be convinced of course), because checkstyle can be set up to
warn only on style issues in the new/touched bits in the PR (or at least
that's how it works in tez), that's what we nee
+1
BTW, We have a independent checkstyle file under iceberg module
https://github.com/apache/hive/tree/master/iceberg/checkstyle . I think we need
to consider unifing the checkstyle in all the sub-module.
Thanks,
Butao Zhang
Replied Message
| From | Zsolt Miskolczi |
| Date | 1/8/2
+1
In case there is an agreement about the coding style, we can prepare a tool
that enforces that style at compile time. Run a tool one time to re-format
all the existing code once. And turn on a compile time check. Iceberg did
the same approach, they had one huge commit with almost 4k files chang
In confluence, page names should be unique in a given space. As I see,
Apache Hive has its own space.
And now comes the tricky part: with 4.0 documentation, we didn't create a
new space, just a 4.0 parent page. We create a copy of existing pages under
the umbrella of this page:
https://cwiki.apache
11 matches
Mail list logo
