On 09/18/2014 08:26 AM, Ivan Zhakov wrote:
> On 11 September 2014 18:03, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Mike,
>
>> 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.
> This is a case when the code contains so many complications and
> unclear design and implementation issues that nobody can effectively
> review it.
Thanks for explaining, Ivan.
It sounds to me, then, as if you are a bit more concerned with code
complexity, bus factor, and the detrimental performance that result from
this feature than with "code quality" per se. The nomenclature matters,
because an accusation of poor /quality/ in code will inevitably come
across as a slant at the developer. (Code of the highest quality can
still be complicated and result in decreased performance of the
application.) Now, most of us would probably agree on whether a given
piece of code is written with quality. But depending on our own comfort
with the nuances of the language, our knowledge of the code context,
etc., we might all disagree on whether it's "too complicated". The bus
factor thing is similarly difficult to measure. Moreover, I recall
seeing conflicting bits of information addressing the performance
aspects of the feature. It would seem we are without a gold standard of
sorts for these more fuzzy determinations of the value of the change.
Unfortunately, this all makes your case for removing the feature a
harder one to press.
It's unfortunate that there are essentially only two technical voices in
this discussion and that they stand in opposition to each other. Brane,
I, and others have weighed in a meta level, but have offered essentially
nothing that would help to resolve the /technical/ standoff (that I
recall seeing, at least). Having reviewed the mailing list thread, I
did see an effective +1 from Philip on merging the branch to trunk[1]
(which does not require him to prove that he groks the change). Daniel
also explicitly +1'd the statement that getting the feature into an
alpha release would be a better way to test it[2], but that of course is
not a value judgment of the change itself. Your suggestion for a vote
on the branch being merged wasn't out of line given the amount of
contention over the issue, but the suggestion never stuck -- that's just
life in a community of equal voices.
My opinion, FWIW: I know nothing about the technical details of this
change. But I am confident that it is unwise to move forward with
things in the state they are today, where "state" includes the code
itself and what we know about its bus factor. At a minimum, the
community needs to establish that this feature and its side-effects are
understood by more than just the one smart guy that wrote it and the
other smart guy who isn't a fan. Then, those who understand the feature
and its side-effects need to publicly weigh in on both the value and the
timing (1.9, FSFS rather than FSX, etc.) of the change. Sure, there's
nothing in Ye Olde HACKING that requires this stuff, but these are the
kinds of concessions that communities of volunteers make -- for the good
of the community and the project -- when the typical patterns are
failing. And if someone wants to go on record as opposing such a
simple, simple exercise that could go a long way towards community
harmony ... well, so be it. In my mind, it's their own credibility at
stake. How do you manage this discussion in the simplest way possible?
Call for a formal vote on removing the feature, asking that the extreme
+1/-1 votes be presented only by folks who both understand the feature
and have reviewed the code. (Seems only fair to allow the status quo to
remain the default action.) Give the vote at least 72 weekday hours to
allow time for code review, and then put this topic behind you/us and
move on.
My $0.015.
-- Mike
[1] http://svn.haxx.se/dev/archive-2013-11/0191.shtml
[2] http://svn.haxx.se/dev/archive-2013-11/0267.shtml
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2014-09-18 17:08:47 CEST