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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
