The ``obvious fix'' rule.

The ``obvious fix'' rule.

[Andrew Cagney]

[*NOTE* Reply-to: set to gdb@sources.redhat.com.  Reply-to is bad M'kay]
(just moving a discussion on gdb-patches across to the discussion group)

Hmm, I looked at one of the postings and it occurred to me that yes it
was probably a good time to discuss this one. - January is always a slow
month.  Looks like the boat left without me :-)

Anyway, yes, at present GDB doesn't have an obvious check in rule
(although some people have probably been sneakering in changes in the
basis that it does :-).

Instead, people listed under the blanket write privs list are free to
check in anything.  If something is really really obvious then, they'll
just check it in without reference to other maintainers.  In general
though, the blanket write privs maintainers go out of their way to not
step on the toes of the maintainers of specific areas.  I've observed on
several occasions that getting onto the Blanket Write Privs list gives
you less not more freedom :-)

I think the recent problem with a C++ related core dump is probably more
of an example of an unfortunate sequence of events than justification to
introduce an obvious fix rule.  Maintainers can't veto for fail to
respond to a patch because they are just about, real soon now, like the
cheque is in the e-mail, just getting it out the door, as we speak,
going to post the worlds greatest rewrite of a given piece of code. 
Instead maintainers need to allow people to incrementally improve the
existing code base.

For me personally, juggling this is really hard - I have to ask the
question: is this change, while not perfect, still taking things in the
right direction - does it take things forward more than sideways?  There
are two things (more?) that I do tend to dig my heels in with though:
interfaces and coding standards.  In both cases it is because I think
GDB is littered with examples of where standards were dropped and now we
are still paying the price for dropping our guard :-(.  For interfaces,
I think it is important to put significant effort in trying to get them
right.  It is the interfaces and not the implementation that is going to
last for very long time.  With coding standards, I've two concerns: bad
code has this nasty habit of breeding (believe me :-) and I've a strong
preference for keeping code as readable (dumb it down) as possible. 
Many many many many many many many more people than the author are going
to need to read/understand that code.


(Any way, returning to your regular program)
So what about an obvious fix rule?

To show my colours (note spelling :-) I've found that too often what is
claimed to be an obvious fix is unfortunately wrong.  Rather than fixing
a problem it just hide it, or worse, the patch will often take the the
code base in directions it just shouldn't (the twilight zone of
maintainability).  A favourite obvious fix involves bypassing interfaces
and grubbing around in internals (ex registers[]).  The thing that will
really get up my nose is someone making a change, and then announcing it
after the fact with the claim it is an obvious fix :-)


Against all that, there is an obvious needs to further loosen those
purse strings:

	o	GDB must compile
		syntax errors and configury problems

	o	GDB must not dump core

	o	GDB must meet coding standards
		(you can all roll around and laugh
		at this one :-)

	o	others?


Must compile - syntax errors: I guess this has to go into the obvious
fix with notification after the event category.  After all, this will
never occur will it.

Must compile - configury changes: People are already free to tweak
Makefile.in and configure.in.  Just ask for comment first.  Extending it
to other files (adding autoconf stuff) makes sense and I suspect people
have already being doing that :-)

Must not dump core: more tricky.  Since there is now a gdb_assert()
macro, I'm very tempted to suggest that the obvious fix to a core dump
is to add ``gdb_assert (dud_pointer != NULL)'' :-)  Beyond that, things
typically do need review.  Flame away.

Must meet coding standards - spelling: This one has already become an
obvious fix rule.  But remember those cultural sensitivities.

Must meet coding standards - style: At present developers get a licence
to eradicate things (cf Kevin's work).  To be honest, I think this is
working.  It means that code improvement maintaining a certain pace
without getting out of control.  It also means that we're not spending
all our time fixing non- problems :-)

Other thoughts?

	Andrew

Re: The ``obvious fix'' rule.

[Stan Shebs]

Andrew Cagney wrote:
> 
> To show my colours (note spelling :-) I've found that too often what is
> claimed to be an obvious fix is unfortunately wrong.  Rather than fixing
> a problem it just hide it, or worse, the patch will often take the the
> code base in directions it just shouldn't (the twilight zone of
> maintainability).  A favourite obvious fix involves bypassing interfaces
> and grubbing around in internals (ex registers[]).  The thing that will
> really get up my nose is someone making a change, and then announcing it
> after the fact with the claim it is an obvious fix :-)

In GCC-land, "obvious fix" means that there is no possibility that
anyone will disagree with the change.  Something like bypassing an
interface will result in instantaneous and loud complaints, and so
committers tend to be pretty careful about only putting in the
genuinely obvious without prior review.  Even so, sometimes things
have to be reverted if a committer gets overconfident.

Perhaps a good mental test is "will the person who hates my work
the most be able to find fault with the change" - if so, then it's
not obvious and needs to be posted first. :-)

Stan

Re: The ``obvious fix'' rule.

[Christopher Faylor]

On Tue, Jan 16, 2001 at 05:32:42PM -0800, Stan Shebs wrote:
>Perhaps a good mental test is "will the person who hates my work
>the most be able to find fault with the change" - if so, then it's
>not obvious and needs to be posted first. :-)

I think that this is the best criteria for an "obvious fix" that
I've ever heard.

cgf

Re: The ``obvious fix'' rule.

[Andrew Cagney]

Christopher Faylor wrote:
> 
> On Tue, Jan 16, 2001 at 05:32:42PM -0800, Stan Shebs wrote:
> >Perhaps a good mental test is "will the person who hates my work
> >the most be able to find fault with the change" - if so, then it's
> >not obvious and needs to be posted first. :-)
> 
> I think that this is the best criteria for an "obvious fix" that
> I've ever heard.

You're meant to say the ``most obvious criteria'' ... :-)

A voting schema for issues was also suggested.  At present we've got
what I'll refer to as a consensus approach.  I think this is much better
than a so called vote and I think it better reflects how internet
discussion really operates.  A discussion, assuming people can remain
focused, normally reaches the point where, appreciates understands the
decision.  A voting system, by its nature, typically alienates 49.9999%
of the population.

	Andrew

Re: The ``obvious fix'' rule.

[Andrew Cagney]

Stan Shebs wrote:
> 
> Andrew Cagney wrote:
> >
> > To show my colours (note spelling :-) I've found that too often what is
> > claimed to be an obvious fix is unfortunately wrong.  Rather than fixing
> > a problem it just hide it, or worse, the patch will often take the the
> > code base in directions it just shouldn't (the twilight zone of
> > maintainability).  A favourite obvious fix involves bypassing interfaces
> > and grubbing around in internals (ex registers[]).  The thing that will
> > really get up my nose is someone making a change, and then announcing it
> > after the fact with the claim it is an obvious fix :-)
> 
> In GCC-land, "obvious fix" means that there is no possibility that
> anyone will disagree with the change.  Something like bypassing an
> interface will result in instantaneous and loud complaints, and so
> committers tend to be pretty careful about only putting in the
> genuinely obvious without prior review.  Even so, sometimes things
> have to be reverted if a committer gets overconfident.
> 
> Perhaps a good mental test is "will the person who hates my work
> the most be able to find fault with the change" - if so, then it's
> not obvious and needs to be posted first. :-)

Assuming no one objects, I'll add this to the MAINTAINERS file.

	Andrew

Re: The ``obvious fix'' rule.

[Andrew Cagney]

Well, no one objected so ...

Stan Shebs wrote:
> 
> Andrew Cagney wrote:
> >
> > To show my colours (note spelling :-) I've found that too often what is
> > claimed to be an obvious fix is unfortunately wrong.  Rather than fixing
> > a problem it just hide it, or worse, the patch will often take the the
> > code base in directions it just shouldn't (the twilight zone of
> > maintainability).  A favourite obvious fix involves bypassing interfaces
> > and grubbing around in internals (ex registers[]).  The thing that will
> > really get up my nose is someone making a change, and then announcing it
> > after the fact with the claim it is an obvious fix :-)
> 
> In GCC-land, "obvious fix" means that there is no possibility that
> anyone will disagree with the change.  Something like bypassing an
> interface will result in instantaneous and loud complaints, and so
> committers tend to be pretty careful about only putting in the
> genuinely obvious without prior review.  Even so, sometimes things
> have to be reverted if a committer gets overconfident.
> 
> Perhaps a good mental test is "will the person who hates my work
> the most be able to find fault with the change" - if so, then it's
> not obvious and needs to be posted first. :-)
> 
> Stan