Date: Wed, 20 Feb 2002 19:55:45 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Greg Lehey <grog@FreeBSD.ORG>, Jake Burkholder <jake@locore.ca>, David O'Brien <obrien@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: Patch to improve mutex collision performance Message-ID: <3C746FC1.897E759C@mindspring.com> References: <200202181912.g1IJCGK32122@apollo.backplane.com> <20020218114326.A98974@dragon.nuxi.com> <200202181951.g1IJpip33604@apollo.backplane.com> <20020218153807.E96115@locore.ca> <20020221111915.N65817@wantadilla.lemis.com> <200202210146.g1L1kqg91511@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > I'm not interested in using P4. I think it's a mistake. That is, I > think it is being severely overused. At the very least it is preventing > me from comitting simple things to -current because as far as I can tell > when you add up the junk sitting in P4 it touches almost every file > in the kernel tree. Everything I've tried to work on has some hack > sitting in P4 somewhere that somebody hasn't committed. By the same token, you have also stated: ] Well... try again. If something ought to be compatible in a piecemeal ] commit and isn't, then something unexpected happened and you need to ] find out what it was. Doing a full-on commit for something like the ] proc lock patch is far too dangerous. It's just too large a patch set ] and we know from experience (cam, softupdates, etc...) that having a ] small handful of people testing a large private patch is not going to ] find all the bugs. How do you reconcile these divergent points of view? > I would like to see John commit his ucred stuff with Giant > instrumentation. If he doesn't want to do it then I would like him > to give me permission to do it from my tree now. I see no reason why > we should have to wait another X days or weeks to see this stuff in > the main tree. It just makes no sense to me. What large scale changes are "OK", and what large scale changes are "too dangerous"? Do you have a set of rules, that would let us look at a patch set and instantly decide which of these two categories the code fell into? I'm not trying to be a jerk, but not everything can be broken down into 1 line commits, and not everything can be broken down into 8 line commits, or 64 line commits, or 512 line commits, etc. (if you'll forgive my proof by induction). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C746FC1.897E759C>