I've created the following PR based on this discussion and the document
that I've started to prepare last year:
https://docs.google.com/document/d/17EEKT6fih9Dd5NfXjBoECcKbVp1eOB2vb3jKqTF9pPc/edit
.
https://github.com/apache/incubator-druid/pull/7991
I believe having agreed upon development pri
A quote from Steve Tockey regarding documentation and comments and the cost
of maintaining software:
https://medium.com/@leventov/steve-tockey-on-software-documentation-and-comments-470751227a63
On Mon, 29 Apr 2019 at 19:30, Fangjin Yang wrote:
> Strong +1 agreement with Gian. I definitely see t
Strong +1 agreement with Gian. I definitely see there are anal code reviews
focused too much on trying to force changes that make no difference to the
core functionality being contributed, and are instead a reflection of
personal biases of the reviewer. These types of low quality code reviews
provi
+1
As someone who reviews Druid release candidates but does not develop Druid
code, I wish that “mvn test” would “just work”. I can imagine that first-time
and occasional contributors are in a similar boat to me.
I know this is not an easy thing to achieve, because the test suite also has to
w
As a new contributor, I've actually really appreciated the careful and high
quality code reviews I've received (primarily from Jihoon).
The real source of friction for me has not been the feedback from
developers, but the painfulness of running the tests.
- Figuring out how to locally run the ful
On Wed, 24 Apr 2019 at 00:10, Gian Merlino wrote:
> Well, I think this is a good reason to have a robots-only policy for code
> style checking. The fact that I am one of the few people that can adhere to
> the unwritten style rules, because I've been working on Druid for over 7
> years, means tha
> Reviewers can help by making their first review as comprehensive as
possible,
Just want to point out that sometimes it's hard to understand the PR author
intent without asking initial questions which could subsequently create a
bunch of "one-line emails". Probably those places in the code should
Hey Roman,
Thank you too for participating.
> Apart from code review friction, I think there is another important
> (ultimately, more important) problem/goal for the long term project
success
> which cannot be discussed separately: keeping the codebase highly
> maintainable. I'm a Druid developer
I am coming from a long break and good to see community becoming bigger and
people caring about ease of contribution.
Thanks Gian for starting this thread and I have had similar perceptions in
the past.
1. Absolutely Agree on automating most style comments possible and try to
get as close to 100%
Hey Slim,
Thanks for reading. Some thoughts inline -
>> 1) "Let robots handle style checks."
> OMG Gian, are you taking away all the fun? what is code review without
> arguing about the meaning of life and code style, variable names etc ??
> Totally agree, we need to avoid as much as possible co
Apart from code review friction, I think there is another important
(ultimately, more important) problem/goal for the long term project success
which cannot be discussed separately: keeping the codebase highly
maintainable. I'm a Druid developer for about 2.5 years, and I definitely
feel that makin
On Mon, Apr 22, 2019 at 7:43 PM Gian Merlino wrote:
> Hey Druids,
>
> Sometimes I feel like this too:
> https://twitter.com/julianhyde/status/1108502471830204416.
>
> I believe our code review process today has too much friction in it, and
> that we can work to reduce it. The two main frictions I
12 matches
Mail list logo
