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).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message