On 09/18/2014 08:26 AM, Ivan Zhakov wrote: > On 11 September 2014 18:03, C. Michael Pilato <cmpil...@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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
