Date: Sun, 23 Apr 2000 20:58:46 +0000 From: Mike Muir <mmuir@es.co.nz> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: To MFC or not to MFC, that is the question. Message-ID: <39036406.A256278@es.co.nz> References: <10801.956522360@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jordan K. Hubbard" wrote: > > > 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 > two. > > 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. :) <me too> I'll be your CRC and say stop yer bickering and discuss this like adults (assuming you both are infact classed as such) which means no cheap shot insults (im sure you both have great memories and excusing that would be your workloads which im sure are right up there) and getting over whatever personal differences either party might have. ok good! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39036406.A256278>