This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Procedural issues and consensus building (was Re: UCNs-in-IDspatch)


Meta-note: I have reordered the various paragraphs of what you wrote
as suits the rhetorical flow of what I'm writing.

Geoff Keating <geoffk@geoffk.org> writes:
> I've learnt that I should stop trying to get public review of my
> significant patches before committing them, because it's mostly
> useless.  I've learnt that there's no point arguing with people who
> do not accept reasoned argument.  I've learnt that in the cases
> where public review would have been helpful, all the unhelpful
> comments are so annoying that I often miss the helpful ones.

Any discussion of the IMA and PCH implementations, at the time they
went in, is sufficiently far in the past that I do not clearly
remember it.  However, I do clearly remember the argument over
extended identifiers.

Are you sure that you are not conflating "has an objection in
principle to the feature" with "refuses to accept reasoned argument"?
I ask because when I objected to the original extended identifier
patch, I was raising an objection on principle (and secondarily on
development cycle timing).  Furthermore, I was convinced by reasoned
argument (mostly made by Joseph) to retract that objection on
principle.

The present state of affairs with the extended identifier patch is
rather different.  There is quibbling about minutiae, there is grave
concern about introduced bugs, but those are being adequately
discussed elsewhere and I am confident they will be resolved in due
course.  What remains is a procedural issue, namely your choice to
ignore objections (and all you'd have had to do to satisfy mine was
promise to address the various things on the checklist in subsequent
patches, but you still have not done this)...

> What's more, I am starting to learn that I do not like contributing
> to GCC.  I am starting to feel like every time I improve GCC, I get
> criticised for it.  I did not have to try to make the implementation
> anywhere near as extensive as it is, and I did not have to try to
> get it into FSF GCC.  I am very unhappy that my attempts to "play
> nice" have been met with complaints and criticism, because it means
> that I'm going to have to choose between trying to play nice and
> avoiding complaints. 

This reminds me of a common dysfunctional feedback loop I see all the
time in a certain other project, which I will describe as "avoiding
responsibilities in order to punish those who nag one to fulfil one's
responsibilities".  It's an understandable human reaction.  I have
done it myself.  It is a feedback loop, because the naggers will only
stop nagging when one does fulfil one's responsibilities.
Furthermore, the pool of naggers inexorably grows the longer those
responsibilities remain unfulfilled.  Which, of course, only increases
the desire not to do anything because then the naggers will have won.
It is dysfunctional both because there is something at the root of the
dispute that is needful but not getting done, and because the feedback
loop is liable to blow a minor dispute up into a mailing-list-eater of
a flame war, which drains time, attention, and emotional energy away
from *other* needful things.  It happens all the damn time over in
that certain other project.  So far we've been able to avoid it here,
and I hope we can keep it that way.

I will freely admit that some of my criticism in the past has not been
constructive.  I intend to do better in the future.  But just as you
feel that your time is wasted by unhelpful criticism or outright
hostility, I feel that my time is wasted when I have written what I
think is constructive criticism and it goes unheard.  And just as you
are tempted to ram patches through, I am tempted to stonewall without
justification.  Either way, we all lose.

> I am unhappy that I have had to work on this at all, it should have
> been resolved years ago.  I am unhappy that when I tried to work on
> it, instead of being met with help and thanks for taking on the
> problem, I was met with rejection.

So here's a question.  Why did you, out of the blue, decide to
implement this particular feature?  Yes, it has been sitting in the
pile of unimplemented features for ages.  Yes, it's one of the
tick-list items we have to complete for full C99 and C++98 compliance.
However, I've seen *one* user request for it in my seven years of
working on the C front end, and it was not phrased in an urgent
manner.  I fully intended to get around to it one day, hopefully after
some of the specification issues had been ironed out.  

Your phrasing and tone, however, indicates that you see it as an
important missing feature, one that should be implemented
immediately.  Furthermore, you tried to get it in in the
bug-fixes-only phase of GCC 4.0 development, which also suggests that
you see it as a very important feature.  I can only conclude that you
are seeing user demand that I'm not.  Where is it coming from?

> I've learnt that some people seem to think that it's their right to
> complain about design or implementation without being willing in any
> way to contribute.  I've learnt that some people will create a
> "mood" which has no basis in reality.  I've learnt that some people
> seem to think that someone who is willing to do 50% of the work
> should be willing to do 100% of the work, even when they themselves
> are unwilling to do any of the work (people plural, not just Zack).

In some cases, yes, I do think that someone who is willing to do 50%
of the work should be willing to do 100% of the work.  This is one of
these cases.  50% (I suspect more like 10%) of the work has been done:
the spiffy new feature has been implemented.  In so doing, a pile of
bugs of indeterminate size has been introduced.  The remaining 50%
(90%) of the work is fixing those bugs.  It has always been our policy
that the person who introduces the bugs is on the hook to fix them.

I have not complained when I was the one stuck doing more work than I
had anticipated: my patches to fix serious bugs in the C front end's
identifier-to-decl mapping took somewhere between three and five
months of additional coding time (spread over the course of a full
year!)  because of IMA, and when I asked for help, none was
forthcoming.

> I've learnt that the best is not just the enemy of the good, but
> that it has sympathisers, and some of those think that even the best
> is not good enough.  I've learned that there are useful features
> which are intentionally being left out of GCC, even though they
> would benefit users, simply because of some trivial difficulty which
> users will probably never encounter.
>
> I've also learned that in each of the two cases above, and I expect
> in this case, that *I was right and those who objected were wrong*;
> and I have a conclusive piece of evidence for this, which is that
> no-one has yet come up with better implementations, and so even if a
> replacement was developed tomorrow, users have still had the ability
> to use these features for several years more than had I not written
> them.

In the cases of PCH and IMA, there are those who would argue that what
you gave us is worse than nothing at all.  That the reason no-one has
yet come up with a better implementation is because your
implementation stands in the way.  That the damage done to common code
in the name of these, yes, desirable features has made it harder to
get anything else done in the source tree.

I do not agree with these claims: I think what you did is as good as
could have been accomplished in the time you had.  I would have done
it differently - and I probably would not have finished either
feature.  Furthermore, I think we can get to something better by
incremental refinement: a concerted effort to minimize the set of data
structures involved in PCH, for instance, would be very helpful (this
should not be confused with an effort to minimize the set of data
structures subject to GC, which I think would be counterproductive).

Returning to the meta-discussion, though: If you had discussed your
plans in advance, if you had borne the complaints and engaged your
critics in thoughtful discussion, it is likely that people would not
now be accusing you of sticking us with worse than nothing at all.
You could have made people understand that what you were doing was the
best that could be done in the time available, and you could have
convinced us that it was worth it.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]