This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 3.4 regressions: are 2.95 regressions still actual


In article <4195D82C2DB1D211B9910008C7C9B06F01F37408@lr0nt3.lr.tudelft.nl> you write:
>Milestones are only meaningful if the bugs actually are important enough
>to somebody to fix it.  As has been pointed out by our RM several times,
>GCC is a volunteer project and he doesn't think pushing volunteers to do
>something would help.  All this policy does at this late stage is make
>the compiler look far worse than it is in reality.

I must be totally non-political, or completely thick.

A bug is  a bug. Targetting it for a release is a political/technical
decision. There are critical bugs, because not fixing them will cause
problems to a lot of people. There are less critical bugs, with known
and documented work-arounds, or that affect only a few people.

But I really must disagree about your apparent mode of thinking.
Wherever you target bugs, it does change absolutely NOTHING about how
the compiler is.  It can't be better or worse just because you change
the release on bug reports.

Heck, even the way the compiler `looks' is irrelevant.
It looks exactly as good as it can considering the number of bugs that
are KNOWN about it, no matter when they're targetted to be fixed.

If you start taking into account the timeline of bugs and announce
`gee, gcc 3.4 has 30 bugs' (and we conveniently swept an extra 10 bugs
under the carpet for 3.5), that's a blatant lie.

Choosing not to fix bugs for a given release is a technical decision:
it's about applying scarce resources to an impossible problem.

And targetting bugs for sooner or later doesn't change a single thing
about how good or bad the compiler is.  If you manage to fix every
bug targetted for 3.4, that might means you have a good release
process (at least, it meets the goal of fixing the bugs it decided
to fix).   The compiler stays just as bad, with lurking bugs that
need fixing.


Or just as good, actually. But hey, shipping releases reasonably on time
is already something to be proud of. And having better control quality
is good as well. 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]