On 09/10/2014 05:37 PM, Branko Čibej wrote:
> > I have technical objections related to the general quality of the
> > new code. The best way to find out more is to review this code by
> > yourself!
> No. It's your veto and therefore the burden of evidence is on you.
> "General quality of code" is the same kind of nonsense argument as
> "code churn." By that criterion, we'd have never released 1.0.
> Throwing diffs my way that you know damn well I can produce myself is
> just avoiding the issue. You're obviously able to point out concrete
> problems in other parts of the code, so I can't understand why that's
> so hard in the case of log addressing. Maybe you see issues there that
> I missed, so please, once again, take the time to point them out. You
> may even help the author learn something.
> Sure, it's a lot of work. So is writing this mail on a phone while
> lying in hospital, but no-one else is likely to do it for me.
Branko: Actually, I was going to write it for you, but you beat me to
it. :-) Ivan, I honestly don't want to "pile on" here, but Branko is
Ivan: As a reviewer of the code in question, there's really no way you
could have established (for yourself) a legitimate objection about the
"general quality" of the code without first spotting some /specific/
things that bothered you. Of course, if while reviewing the code you
spotted so many such specific things that you lost count or couldn't
keep track, that general concern would emerge. That's all completely
natural, and it would be silly for anyone to claim that your concern
about a bit of code's quality is a bogus feeling. Unfortunately,
"general concerns" aren't portable. If you wish to adequately
communicate your concern to anyone else in hopes that they, too, agree
that the code needs to be fixed, you're going to have to stop talking
about the effect of your review (general concern) and return to the
fundamental causes that created that concern -- specific code defects.
Depending on how fresh in your mind the code is, this may mean
completely reviewing the code again for yourself, making shareable notes
about the problematic code bits one by one as you do so. That is, you
need to offer a typically line-by-line, block-by-block code review
yourself. I'm not claiming that this will be enjoyable, but it is what
is required in a community of volunteers.
Received on 2014-09-11 16:04:49 CEST