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]

Re: Beyond GCC 3.0: Summing Up


On Tue, Jul 10, 2001 at 04:37:28AM -0300, Alexandre Oliva wrote:
> But by keeping the patch in, we'd be encouraging everybody to take
> responsibility for fixing it.  Why place the burden on the very person
> who's already done us the favor of fixing one bug?
> 
> > The poster would want to get her patch checked
> > in, so she would either fix the latent bug, or lean on other people
> > to fix it.
> 
> And if the patch remained in, more people would be leaning other
> people to fix it :-)

Isn't using (CVS) branches a solution here?  Or perhaps just a compromise?

..
> I believe my point still holds: why would we approve a patch that
> introduced a regression in a test case (reverting the patch that fixes
> a bug)?

That is not a REAL regression.  Mark is ONLY concerned with regression
relative to already released versions of gcc, not with bugs that are
discovered and (temporally) fixed in the cvs developers version.
And I think he has a point.  This means:

version 3.0 can do: "A" and "B".
version 3.0+ (cvs) can do: "A" and "C".
nobody fixes "B".
Mark wants: revert the last patch get "A" and "B": no regression.
You seem claim that reverting that patch breaks "C" and therefore
introduces a regression?

My opinion is that it doesn't hurt to have the patch for C in the cvs
but a release is impossible until B is fixed too.  If there is a release
date at some point it should be possible to decide which patches will
have to be reverted and for which people will try hard to fix "B".

-- 
Carlo Wood <carlo@alinoe.com>


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