This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Patch fixing 3.3 bug PR 9745 and PR 10021
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: Jim Wilson <wilson at tuliptree dot org>
- Cc: Mark Mitchell <mark at codesourcery dot com>, Michael Matz <matz at suse dot de>, Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>, Marcus Meissner <meissner at suse dot de>, gcc at gcc dot gnu dot org, Olaf Hering <olh at suse dot de>, dalej at apple dot com
- Date: Wed, 09 Jul 2003 11:30:02 -0400
- Subject: Re: Patch fixing 3.3 bug PR 9745 and PR 10021
>>>>> Jim Wilson writes:
>> According to the GCC Development Plan, which describes
>> responsibility for fixing bugs, David Miller is reponsible for fixing the
>> latent bug that his patch exposed.
Jim> This is not constructive. David Miller's patch was a useful gcc
Jim> reorganization. It is unavoidable that major useful changes will
Jim> require some later bug fixing. If we require people contributing major
Jim> useful changes to fix every bug caused by that patch on demand until the
Jim> end of time, then no one would ever be able to make any major change
Jim> because no one can realistically make that kind of commitment. There
Jim> should be a statute of limitations to this clause, and David Miller's
Jim> patch should be considered past the statute of limitations because it
Jim> was over a year ago, thus we should not be requiring David to fix this
Jim> problem.
I appreciate that you are trying to be productive and so am I.
Labeling and characterizing my comments does not promote an open
discussion.
Maybe there should be a statute of limitations, but the GCC
Development Plan does not mention one.
You want to get on to other work, I want to get on to other work,
and David Miller wants to get on to other work. Part of the motivation
for the Development Plan bug responsibility policy is an attempt to avoid
some GCC developers spending time cleaning up after other developers
instead of making progress on their own projects. Dale, Geoff, Olaf, and
I already have spent a tremendous amount of effort investigating and
trying to solve the bug. Everyone appreciates your recent effort and new
insight.
Correcting alias.c implementation to follow the description at the
top of the file and causing performance problems seems like passing the
buck to me. GCC development should not be a game of "hot potato". I
cannot speak for Dale, Geoff, and Olaf, but I eagerly offer my continued
effort to help solve this problem. However, I do not believe that a GCC
developer should knowingly introduce a bug or performance regression and
force the responsibility for solving the problem onto another developer or
group of developers.
David