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

Reply via email to