This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.5 Status (2004-08-29)
Gabriel Dos Reis wrote:
Mark Mitchell <mark@codesourcery.com> writes:
| Gabriel Dos Reis wrote:
|
| >Making regular bug-fix releases at regularly spaced times makes good
| >sense to me. What I'm unclear about is what we want for the *major*
| >releases. Do we just want them every 6 months? Do we drive it by
| >quality? If by quality, what are the quality criteria? I suspect
| >
| We cannot drive it purely by quality, since we will never get quality
| unless we decide that we're going to make a release. The level of
| bug-fixing activity goes up steeply as we approach a release: people
| start to fear that "their" platform/language/etc. will not work well.
| That's why we use a combination: drive by time, and then push for
| quality towards that date.
|
| >| they can lead to lower quality, as more and more changes go in,
| >| sometimes without corresponding problem-solving efforts. I also don't
| >| think that "wait until it is ready" is a practical method for a
| >| project this big with this much change and with so much
| >| inter-dependency between components.
| >
| >Again, I agree. However, because the project is that big, I believe
| >branching proposals should meet consensus among developers.
| >
| In contrast, I don't see consensus as achievable in this group. We
That says a lot.
Note that I didn't say "cooperation"; I said "consensus", which means
that everyone agrees.
This is a group that cooperates well, but I don't think it's very easy
to reach consenus among groups with O(100) people. We often don't even
get consensus on technical issues; we often instead defer to a
maintainer to make a decision, or put off making one altogether. When
we do try for consensus, it's often among groups (the C++ maintainers,
people who know a lot about reload, etc.) that are at least two orders
of magnitude smaller than the group as a whole. Even the SC doesn't
always get consensus; we vote, and often have split votes.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com