2007/4/16, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> You want more bugs fixed, it would seem a better way would be to build
> a better sense of community (Have bugfix-only days, etc) and encourage
> it through good behavior, not through negative reinforcement.
I do agree with that in a general way, but I think there should also
be a real effort done by the various maintainers to make sure people
indeed fix the few PRs they created. Maintainers should be able to
say, "please think of fixing this PR before submitting a patch for
that feature". That doesn't introduce administrative overhead, because
maintainers should keep track of the various PRs and patches of their
area. I think it works already for some areas of the compiler, but
doesn't work fine for the "most common" areas.
A few examples of that (maybe I'm always quoting the same examples,
but those are the ones I know that impact my own work on GCC):
-- how can bootstrap stay broken (with default configure options) on
i386-linux for 3 weeks?
-- how could i386-netbsd bootstrap be broken for months (PR30058),
and i386-mingw still be broken after 6 months (PR30589), when the
cause of failure is well known?
These are not rethorical "How", or finger-pointing. I think these are
cases of failure we should analyze to understand what in our
development model allows them to happen.
FX
The "mea culpa" is to permit for long time to modify "configure" instead of
"configure.ac" or "configure.in" that is used by "autoconf" and/or "automake".
Another "mea culpa" is don't update the autoconf/automake versions when
the GCC''s scripts are using very obsolete/deprecated
autoconf/automake versions.
Currently, "autoconf" is less used because of bad practices of GCC.
I propose to have the following:
* several versions of autoconf/automake in /opt that are depended from the
current GCC's scripts. And to set PATH to corresponding /opt/autoXXX/bin:$PATH.
* to do diff bettween configure and the configure generated by autoconf/automake
with configure.ac
* with these diffs, to do modifications to configure.ac
* to repeat it for verifying of the scripts with recent versions of
autoconf/automake
Sincerely J.C. Pizarro
