GCC 3.3, GCC 3.4

[David Edelsohn]

>>>>> Mark Mitchell writes:


Mark> --On Monday, February 03, 2003 03:01:51 PM -0600 Benjamin Kosnik 
Mark> <bkoz@redhat.com> wrote:

>> On 03 Feb 2003 13:32:38 -0700
>> Tom Tromey <tromey@redhat.com> wrote:
>> 
>>> This sounds good to me.  What's the next step?  Maybe suggest a patch
>>> to the development plan?
>> 
>> Sounds good to me.

Mark> It doesn't sound that good to me.

Mark> That's basically a feature-driven approach -- "we want these new
Mark> features".  The problem with that is that we have no way of knowing
Mark> whether people will actually do the work to implement the features
Mark> or not.  To a large extent, this is where we were way-back-when
Mark> before 3.0; we tried to wait until stuff got done, it always took
Mark> longer than anyone expected, while we were waiting other people
Mark> wanted to add in more stuff, that other stuff was buggy, etc.

	Mark, redefining a proposal and then arguing against it is
fallacious reasoning.  That is exactly what you are doing.  I never
suggested extending the schedule indefinitely.

	Either extreme of schedule driven or feature driven development
causes grief.  We need to find a flexible middle ground.  I think our
current schedule places developers in a catch-22 situation that is
discouraging and demoralizing.

	Again, accomodating developers both frees up more developers to
fix bugs in the current release branches and encourages those developers
to fix bugs in the next release branch so that their improvements are
available in a release.  Currently the development process discourages
developers and creates the small pool of people fixing bugs, about which
you have complained.  The current policy is part of the problem.

	GCC releases already are delayed because of regressions and PRs,
so allowing a longer window for integrating recommended goal features will
not make it worse if the same developers are able to help with bug fixes.

David