Re: GCC 3.5 Status (2004-08-29)

[Gabriel Dos Reis <gdr@integrable-solutions.net>]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| >What are our release criteria?  Sorry to ask the trivial, but it is
| >because I'm unclear about what we're after.
| >
| There is no single answer.  The GNU/Linux distro vendors want things,
| embedded people want things, hardware vendors what things, and other
| people want  things.  And, everyone wants the release schedule to line
| up with their own personal and/or organizational schedules.
| 
| As the RM, I want releases that are both timely and of high-quality.
| These two things cannot be entirely traded against each other: longer
| release cycles do not necessarily lead to higher quality.  In fact,

If you're saying that having a release cycle of ten years is not
automatically going make the release of good quality, I can only agree
with you.

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
that question is harder than the previous to answer because we don't
seem to have metrics that throw numbers at us.  I don't think we have
answers for time and quality combined; or at least I'm just unable to
find where we're consistently applying them.

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

| I think that GCC 3.5 is going to be a good release.  I also think that
| the first release with major new technology (tree-ssa is easily the
| biggest change to GCC in a decade) is going to have dot-zero
| properties: it won't work perfectly for all people all of the time.
| Since everyone else (including Oracle, Microsoft, Red Hat, etc.) has
| that problem with huge revisions, I think we will have problems too --
| independently of exactly when we do a release.  Oh, well.

The issue is not whether we're going to have dot zero problems or
not.  But what is knowingly and with consensus decided to be included
in that set.

I'm not trying to make your job harder -- the RM position is alrady
hard enough.

-- Gaby