>    Really, then you have a short memory.  Why don't we ask Jordan for a 
>    clarification.

How about if you let me review the patches in question and I'll render
a decision.

If you, Matt, could put the SMP and linux stuff into -current first
and then give me a day or so to check it out, I'll submit my own
opinion on whether or not this is "immediate MFC" material.

That covers the operational side of the discussion, and on the
procedural side I unfortunately see a lot of arguing about "our
policy" for things like this in spite of the fact that there has never
really been an absolutely clear-cut mandate about when/where things
should be MFC'd.  It's a more complex mesh of judgement calls
revolving around:

     o Whether the change is absolutely mandated by security criteria
       or just-plain-brokenness in -stble.

     o Whether the change is cosmetic or otherwise minor enough that
       there's no reason not to Just Do It right away.

     o How close we are to an impending release in the -stable branch
       in question.  As has been stated frequently in the past, the
       release engineer would prefer for big changes in -stable to come
       along early in the game for maximum testing time rather than
       the day before code freeze starts.

Determining where one sits with respect to all three of these
merge-justification criteria comes down to a judgement call in each
case, not some precise committer's checklist. I also personally don't
mind that too much since no checklist can be written to cover all
cases or codify the full range of "good judgement", so it ultimately
comes down to personal opinion.  I see two very big differences of
personal opinion on this one and am willing to arbitrate between the

In the longer-term, this kind of thing should be handled by the
architecture group or the conflict-resolution committee depending on
whether it's an architectural dispute or a simple clash between
personalities or styles.  In this case, I'd say it was a job for the
CRC if we currently had one. :)

- Jordan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to