Re: gcc 3.5 integration branch proposal

[Daniel Berlin <dberlin at dberlin dot org>]

> 	FSF GCC also has a very large and diverse user community who
> provide conflicting feedback about their priorities:
One way of gauging their feedback is to turn on the voting system in 
Bugzilla.
Since we have bugs for all of these things in Bugzilla, people can vote 
for the bugs that are most commiserate with their goals.
Of course, like all things, this is subject to it's own set of problems.
But right now, the only gauge we get is the mailing lists, and people's 
general feelings reviewing bug reports, neither of which is really 
quantifiable into a hard number we can look at :).


Of course, we could always turn it back off it it just seems to be a 
nuisance.

> * Correct code generation
> * Fewer ICEs
> * Standards conformance
> * Compilation speed
> * Performance
> * Features
> * Release frequency
> * Release timeliness
>
> 	We need to figure out how to balance those goals better without
> losing ground in areas where we recently have been improving.
Some of the problem is that we have people maintaining *large* numbers 
of areas of the compiler, but not fixing regressions (hopefully 
non-controversial) or improving code speed (this may be more 
controversial) in those areas.
That is, after all, part of being a maintainer. It's not just an 
honorary title.
We need more people assigned (not more assignments for existing people) 
to various areas of the compiler, who *want* to be fixing regressions 
and improving speed in various areas of the compiler.
And anyone who tries to argue we don't have the manpower to do this, is 
simply kidding themselves. These people certainly exist, and are, on 
this mailing list.
--Dan