This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Beyond GCC 3.0: Summing Up
- To: Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr
- Subject: Re: Beyond GCC 3.0: Summing Up
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Tue, 10 Jul 01 07:13:56 EDT
- Cc: gcc at gcc dot gnu dot org
I think the proposal isn't to forget completely the good patch.
As I understand it, it is about
1) taking it out temporarily
2) fix the latent bug
3) then recheck-in the good patch.
But how is this process going to be "managed" any better than getting the
latent bug fixed with the patch *in* the tree? What's going to prevent the
"temporarily" from becoming indefinite?
Whether the patch stays in the tree or not, the same person is going to
have to fix the latent bug. Since we're depending on that person's
volunteer effort, we want to make it as easy for that person if we can,
and it's easiest to fix a bug visible in the main tree than one that needs
work to recrease.
Good patchs should not prevent people from continueing their works. I
think that is thee most important point: how to ensure that patch
checked in would not prevent people from continuing their works.
Right, but the situation we're talking about here is not a major breakage
of that scale, but merely some regression test failures on some targets.