* Charles Wilson wrote on Wed, Jan 21, 2009 at 08:47:42PM CET:
> Ralf Wildenhues wrote:
> > I am very sorry that reviewing takes so long. Mostly this is due to
> > time constraints on my side.
>
> On the plus side, your reviews are usually insightful, and lead to ideas
> for better code, like the libfile_$(transliterated implib name) thing.
Thanks.
> > You can make things easier by splitting them into logically independent
> > (hopefully small) pieces. I acknowledge that some of your other patches
> > may not be splittable further.
>
> Part of my tendency to include minor -- easy to review -- changes with
> larger ones is due to (a) see it, fix it, otherwise it'll be forgotten
> and (b) EVERY separate patchset requires an independent full testsuite
> run.
Ah, ok. I can feel the pain. Let's relieve that a wee bit, without
compromising quality too much:
(a) can be addressed with git. Really, git's is flexible enough to
allow for doing many many small commits, even ugly ones, and cleaning up
afterwards. AIUI git is available for Cygwin and MinGW.
(b) There is no need for full testsuite runs for every patch. If two
patches are clearly independent, then one run with both of them should
suffice. If you have a (not too huge) patch series, where things belong
together, and the end point passes the testsuite, then while that is not
ideal, it is still a lot better than nothing; in that case, please note
this, and we can still ask for results of intermediate states if
necessary.
> Not fun. And I don't get many blocks of 5 hours to waste listening for
> the Windows Popup Alert sound. This has little to do with any delays in
> reviewing -- but does tend to make the reviewing process harder. And
> take longer. Which means more !...@#$ testsuite runs. It's a vicious
> cycle, honestly.
I can feel the pain.
> Recent improvements in cygwin-1.7 have once again tamed the popup
> problem on vista -- so at least I don't have to personally attend each
> testsuite run. It's still 5 hours of useless computer tho.
Good.
> MinGW/Msys "native" test runs are still an exercise in whack-a-mole with
> the popups.
Which however makes testsuite additions all the more important: that
way, at least, when we run the suite before a release, we can find
potential regressions. Think of testsuite additions as a way to shift
some of the testing grunt work from yourself over to other users.
> Actually, for 2.4 I think the cwrapper should no longer include the
> --lt-dump-script option; it is no longer really necessary. But I'm
> extremely hesistant to remove it before then; we've had enough
> destabilizing changes in a "stable" release already.
OK.
> > Why is this patch not accompanied by a testsuite addition using
> > -std=c89 -Werror on a program that creates a C wrapper?
>
> Because I am well trained to be allergic to making the test suite take
> even longer. I know it is not fully rational, because tests help us
> avoid these problems in the future. But sweet mother of god is it painful.
We need to work against this allergy. Hope the above to be a first
step.
Just to be sure: you are aware of limiting the testsuite runs to just
those bits that you are adding?
old suite:
make check TESTSUITEFLAGS=-V TESTS="tests/foo.test tests/bar.test" \
VERBOSE=yes
new suite:
make check-local TESTSUITEFLAGS='-v -d -x 27-33'
(another mail coming up for the rest)
Cheers,
Ralf
