GCC 3.5 Status (2004-08-29)

Mark Mitchell mark@codesourcery.com
Mon Aug 30 05:27:00 GMT 2004


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



More information about the Gcc mailing list