This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


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

Re: Binutuls is broken now.


> Date: Tue, 19 Jun 2001 10:59:49 -0400
> From: DJ Delorie <dj@delorie.com>

> > > I said "in general".  And that rule *is* one of the gcc rules.
> > 
> > I know it's a gcc rule, but this is binutils!  If we default to
> > gcc rules, then that needs to be stated somewhere.
> 
> I'm not saying it's a binutils rule now.  I'm not saying we're
> defaulting to gcc rules (If we were, that would be Nick's decision
> anyway).  I'm saying it's a good idea to revert things that don't work
> as well as you expected, and rethink the change, rather than let the
> code stay "broken" until it can be fixed.  In gcc-land, it is
> *required* that such patches be reverted immediately.  Here, I'm just
> saying it's a good idea to do so.
>
> You checked in a patch that, while initially approved, caused
> controversy and broke a very important and visible project, Linux.
> What happens if you're called away from the project for a while?  Will
> the code remain broken, just because you never got around to fixing
> it?  By reverting the patch as soon as you know it's not as good as it
> should be, you're (1) preventing such a case, and (2) encouraging a
> better fix to be found.

Well, I should say first I do agree with the *general* logic of
reverting patches since it seems you think I don't.  We don't
need the same discussion as on the gcc list.

It's just that it isn't *trivially* true that the exact action
you state should be taken immediately by me or another
after-approval person by default (that's one reason they had the
discussion on the gcc list).  I believe it would be just as
logical that a head maintainer tell me to revert it, perhaps
after expecting a follow-up patch from me without (unreasonable)
delay.  Such things need to be stated explicitly either per-case
by head maintainer or in rules.

Since nothing was stated from a head maintainer what action to
take (until very recently, followed by H.J:s immediate reverting
before I got to it), I took the action of least surprise;
i.e. don't revert, but work on a follow-up patch.

> I don't agree that HJ should have reverted your patch.  Either you
> should have chosen to do so, or HJ should have gotten permission.

My understanding was that reverting a patch isn't different to
checking in a patch, so needing explicit approval which I can't
give anyway to general code like ld/ldlang.c.

brgds, H-P


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