Re: [Gdbheads] Re: Feb's patch resolution rate

[Eli Zaretskii <eliz@elta.co.il>]

> Date: Wed, 24 Mar 2004 23:13:31 -0500
> From: Bob Rossi <bob@brasko.net>
> 
> Is quick linear with the size of the patch?

No, not IMO.  A large patch takes longer to review, but it's not true
that a 20-line patch takes twice as much as a 10-line patch.  To me,
most of the reviewing time is spent looking at the current sources
and thinking about potential problems with the patch applied, or
testing the patched version.  These activities don't take time that
is proportional to the patch size.

IMHO, a patch that is too long to be reviewed in reasonable time is
too long, period.  The person who submitted such a patch should be
asked to break it down into several smaller patches.

> To me one month is not quick. Is it to anyone else? Everyone seems to
> ignore this question :)

I think one month is too long.

(There, I didn't ignore it ;-)

> The real question is, what incentive does a maintainer have to review a
> patch quickly?

None, except his/her own sense of a job well done (or not so well
done).

> Also, if the testsuite passes, and the initial patch looks good, why
> would it take so long to accept the patch?

The problem is precisely that: deciding whether the patch ``looks
good''.  It's not a trivial decision to make.  One needs to think
about possible implications of the patch, both in its immediate area
and elsewhere in GDB.  There are no automated procedures for that.
That's why we need human maintainers, and that's why maintainers
don't always agree on whether a patch should go in as is.

> Isn't the definition of "stable" for GDB, "The testsuite works the
> same way after the patch as before"?

You seem to assume that the test suite tests every possible aspect of
GDB.  That isn't true, unfortunately.