This is the mail archive of the 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: gcc 3.5 integration branch proposal

	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.

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