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.3.4 release status report


Joe Buck <Joe.Buck@synopsys.COM> writes:

| On Sat, Mar 27, 2004 at 11:09:52AM +0100, Gabriel Dos Reis wrote:
| >   The number of open PRs targetted for 3.3.4 has grown up to 46
| > (from 41 last report).
| 
| That is a *huge* number of bugs to attempt to fix in the fourth point
| release; an attempt to fix even half that number will probably result in
| 3.3.4 being less stable than 3.3.3.  That's because any bug fix adds the
| risk of introducing a new bug.  Of course, I recognize that you don't
| seriously intend to fix that many, but we need to set everyone's
| expectations correctly.

Hi,

  I fully understand the potential risk of any single patch that gets
applied to branch.  You're right that I don't expect to fix that
number of regressions before releasing -- that is just unrealistic.

  However, If can get rid of the 8 regressions I listed,  I'll
be more than happy.

  With no intent to make Mark feel uncomfortable (the RM position is
where you get everybody wanting to eat you ;-)), I believe that the
gcc-3_3-branch was created too early.  Lots of bugs were found only
later and could not make it into early releases.  That explains a
large part of the impressive release note we got for 3.3.3.  Bugs
and regressions are still being found, that contributes to the
growing PRs; and some were unfortunately introduced in 3.3.3
at attempts to fix other bugs.  That is inevitable, and I trust
everybody commenting on GCC release process understand that.
 
  I think that the critical PR deserve a high priority (a truism,
but that probably needs stating);  however, I also feel that normal
PRs with no disruptive patches should be accepted.  It is true that
GCC-3.4.0 is going out very soon and that it contains an uncomensurable
number of fixes and functionalities.  But that is also the principal
reason why I volunteered to maintain GCC-3.3.x.  It is going to reject
lots of (C++) codes, not because it is much buggier but because it is
much stricter and has some ABI changes.  I do not believe that the set of
bug-fixes we should offer should come in a form of whole-or-nothing,
e.g take ABI change + various (non ABI) bug-fixes or nothing.
If I have simple patches/backports for those, I would be happy, but I
would not push hard to apply disruptive patches.

  I'll put resources to fulfill the release date and criteria for
GCC-3.3.4.

  I hope that clarifies things as your expectations are concerned.

-- Gaby


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