On 29.09.2015 00:41, Konstantin Boudnik wrote:
> Hmm...
>
> Negligence, n. : the trait of neglecting responsibilities and lacking concern
> syn : omission, oversight
"Negligence" usually means continued and repeated (non-)action. In that
respect it's an extremely negative label to use; you're
Raul,
I've fixed most of TODOs you created.
Seems that indentation policy with multi-line parameter descriptions
already defined: "multiline comments in Javadoc tags should be indented by
4 or 5 characters ...".
Please check my changes:
> #1 Yakov, how exactly are you reading the Git history? WIP commits were
> never on master, they were in a feature branch which was merged into
master
> on this commit:
You can check the history of the streamer. I see more than one entry.
Probably, that was mistake on merge - commits were not
On Tue, Sep 29, 2015 at 2:01 PM, Raul Kripalani wrote:
(3) we have no tooling in place. The Ignite community is dominated by
> the people who wrote the code and have become accustomed to reading it day
> and night for years. They have a trained eye to detect weird stuff.
On Tue, Sep 29, 2015 at 3:01 PM, Raul Kripalani wrote:
> Thanks, Cos. I'm glad we sorted this out. Sometimes a chat would be useful
> to establish rapport.
>
> Accusing someone of negligence is *extremely* serious and casts a very bad
> image on the person being attributed with
Thank you you for confirming my point: there was a mistake and it needs to be
corrected. End of story. But instead of simply fixing it and moving on, we are
spending hours x 50 people on reading and writing long emails arguing about
imaginary semantical differences.
There's no need to be
Dmitriy has pointed to me why there's a incorrect perception of me going after
Raul ;) I haven't even noticed the last sentence of the original email. And I
am sorry about sending the email too fast. What I was trying to do is to make
a trivial statement: there's a mistake that needs to be fixed -
Cos, your language seems too harsh for the situation.
No one here is committing negligence. The explanation is simple: people
aren't perfect.
Now, let's take a step back and see the big picture. Around 95% of the
commits in this project are by GridGain personnel (check git shortlog -s
-n) who
Raul,
I still think it is valid to have a peer review and if someone is trying and
spending time to keep code style consistent, it is a good thing. And It should
not matter who gets to fixing the style issues until we have check styles or a
much improved process for reviewing.
Code review
Guys,
I have just reviewed the code and have some comments. 1-2 are very serious
from my point of view.
1. Code is in master. Did anyone checked tests on TC? Moreover, are there
suites for those tests?
2. It seems that work on streamer has been done directly in master. I see
WIP commits, but I
Yakov,
I think it is best to provide the code review comments in the Jira ticket,
and not here. Also, Jira ticket has information on who authored the code as
well (don't think we should be calling names out on the dev list).
Can you please reopen the ticket and provide the link to this
Cos,
I think Raul's point was that coding guidelines are not very clear. I think
Raul thought that he was following the coding guidelines. I don't think
"negligence" is a fair word to describe this.
In my view, we have a couple of omissions in the process on Wiki that need
to be spelled out
Hmm...
Negligence, n. : the trait of neglecting responsibilities and lacking concern
syn : omission, oversight
Doesn't sound catastrophic in my vocabulary, really. Does this
> case of negligence and needs to be addressed accordingly.
translate to "should face a firing squad without a trial of
There has been no negligence, Cos! People are human and make mistakes. End
of the story.
Bringing such negative verbiage to the community helps in nothing.
Everybody is doing their best, I'd like to think so.
In fact, you have shifted the conversation away from the actual topic at
hand. So
One more point about empty lines. I have reviewed our empty line policy and
I don't think I can do a better job describing it. The explanation is
pretty accurate.
However, the main problem with our empty line policy is that, although the
resulting code looks very neat, the policy is just too
Are these official guidelines that are worked-out and communicated by
community? Basically, were they made clear when the project went on the CTR
model? I presume it is/was looking at the wikipage. Hence non-sticking
to them is a case of negligence and needs to be addressed accordingly.
I would
Hey guys,
I have little time now, but before this discussion escalates...
#1 Yakov, how exactly are you reading the Git history? WIP commits were
never on master, they were in a feature branch which was merged into master
on this commit:
Commit: 88acd318b84ce3bff8c061bb34718e0e5f7127fb
Agree about checkstyle. I myself do mistakes even after more than 3 years
on this code base.
Checkstyle is a nice tool, works for many IDEs. For example H2 database
requires
incoming patches to conform provided checkstyle config, I use it right from
Eclipse.
Sergi
2015-09-28 16:25 GMT+03:00 Raul
18 matches
Mail list logo