From owner-freebsd-bugs Mon Aug 14 4:41:13 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id D1ECA37B7AB for ; Mon, 14 Aug 2000 04:41:08 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13OIbd-000075-00; Mon, 14 Aug 2000 13:40:37 +0200 From: Sheldon Hearn To: Darren Reed Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/20572: cannot safely remove COMPAT_43 from the kernel config In-reply-to: Your message of "Mon, 14 Aug 2000 20:58:15 +1000." <200008141058.UAA28241@avalon.reed.wattle.id.au> Date: Mon, 14 Aug 2000 13:40:37 +0200 Message-ID: <438.966253237@axl.ops.uunet.co.za> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 14 Aug 2000 20:58:15 +1000, Darren Reed wrote: > > That's why the option is marked with "[KEEP THIS!]" in GENERIC and > > "You probably do NOT want to remove this as much current code still > > relies on the 4.3 emulation." in NOTES. > > I'm reopening this. > > Why ? > > a) you didn't consult me about whether this was fixed before closing it You're not reporting breakage. You're telling everyone about a characteristic of the kernel source which is already well-known and clearly documented. Therefore, the situation isn't considered broken. > b) that explanation you quote implies there should be further action > taken. Then you have three options: 1) Re-open the PR and assign it to someone who is prepared to do the work of making COMPAT_43 an option (possibly yourself). 2) Leave it closed or suspended after moving into the ``wish'' class. 3) Leave it closed. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message