Re: Reenabling Ada by default

[Richard Henderson <rth at redhat dot com>]

On Thu, Sep 09, 2004 at 09:19:06PM -0400, Richard Kenner wrote:
> #3 is the trickier one.  But what's important to realize is that for the vast
> majority of patches, there's no data of that kind anywhere.  Most of the
> patches you do are in the same category: the only "discussion" is within your
> own skull.
> 
> For the small fraction where that's not the case, there is usually an
> additional difficulty in publicizing that discussion that hasn't been
> addressed here yet and it's not just a resource issue.
> 
> A discussion of a bug will, by its nature, refer to the customer test case,
> which cannot be made public.  Sure, it's possible to "sanitize" that test
> case, but usually not until the bug has been understood, which is *after*
> those discussions.  Even when it can be sanitized earlier, requiring it be
> done before the discussions take place in order to allow them to occur in
> public will put an additional item on the critical path for the customer to
> have their bug fixed.  That's a serious problem.
> 
> So can you be a little more specific about what data you are concerned about
> being preserved?

I'm not surprised that you don't seem to understand what I want here,
because YOU YOURSELF almost never do what I want with YOUR OWN patches
to the middle-end.

While I'm ranting, you are the second worst person I know about
explaining your patches.  The honor of the very worst belongs to
H.J. Lu, and I avoid looking at his mail as often as possible now
because of it.

What I want is a rationale for the patch.  I want a high-level
description of the problem.  I want a description of why the 
patch is correct.  If the patch is only mostly correct, i.e.
hacky, I'd like a discussion of the potential pitfalls if known.

I'm not *usually* looking for the blow-by-blow debugging that
you do in your skull over the course of hours or days while
debugging the problem.  I'll only ask for that if I think your
rationale is incorrect, and that the problem may lie elsewhere.

Take, for instance, Roger Sayle's patch,

   http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01280.html

He is solving what amounts to a trivial problem.  And yet,
he includes a concise high-level description of the problem, 
a concise description of what he believes to be the root 
cause, and a short description of his solution.  It is this
attention to detail, this COURTESY, that makes me want to
read Roger's mail first.

You, on the other hand, have not written seven (7) sentences
in support of one of your patches in at least 3 months, which
is as far back as I had patience to verify in the archives.
I would be willing to lay bets that the true answer is never.
Being prodded for information after the fact does not count.

Almost all of the time your entire patch description is
"This fixes a bug that occurred in the ACATS test."  Which is,
frankly, unacceptable.  We've bitched to you about this multiple
times.  If when it comes time to post a patch you can't remember
any more details than that, you should be taking notes.

What I want is something that will be useful to someone in the
future when they encounter a problem in an area touched by the
patch that you're writing today.  I want them to be able to go
back, look at the post containing the changelog entry, see the
rationale and say "Oh, I hadn't thought of that", or "Oh, that
case is handled by the froboz module, which post-dates the patch;
this is probably dead code now".  Or whatever.

What I do NOT want is for them to find the patch with nothing
describing it other than "this fixes a bug in ada".  Or worse,
a mega-merge patch which has not even the one line non-description
of which you are so fond.

> Sure, but that "manner" is significantly different when somebody with
> maintainer privilege on a part of the compiler is doing the patch, as would
> be the case with all ACT folks patching the front end, vs. somebody who
> doesn't have such a privilege.

FALSE.

Global and language maintainers should be following the same rules
as everyone else wrt patch documentation.


r~