Testing and/or patch review (was: [PATCH] Fix several build warnings)

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Thu, 8 Mar 2012 00:41:10 -0800, David Miller <davem@davemloft.net> wrote:
> Thomas did you run a test build and testsuite run for both sparc32 and
> sparc64 on those Sparc NPTL changes you checked in today?

You mean ``Get rid of superfluous assignments in sem_timedwait'', I
guess?  I just posted the patch; Ulrich checked it in.

> I do that for every change I commit, and as sparc glibc maintainer
> since it's my responsibility I'd appreciate it if either you
> explicitly state you did the full validation or you ask me to do
> so for you.

I have not tested it.  I should have CCed you when submitting it.  But
then, it really is obvious from looking at the code.

Generally, I agree about testing, but in some cases I suggest that we can
go by peer patch review instead of spending a considerable amount of time
for setting up testing, etc.  (It's not that the glibc testsuite would be
prepared for catching all kinds of errors; it's just *one* affirmation
that a patch doesn't break anything.  You can change a lot of glibc code
without the testsuite triggering.  Of course, obviously, the testsuite
still does have its right to exist, but it's not the only method for
testing a patch.)

The same applies to the additional cleanup patches that I posted in this
very thread.  In my opinion, these can also be committed without
testsuite testing, after having been reviewed by someone else.

Comments?


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature