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: 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


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