From owner-freebsd-amd64@FreeBSD.ORG Mon May 15 21:37:53 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB3DD16BC1D for ; Mon, 15 May 2006 21:37:53 +0000 (UTC) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2212043D49 for ; Mon, 15 May 2006 21:37:53 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id B38E9998F2B; Mon, 15 May 2006 23:37:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TnNvS+wa-WHB; Mon, 15 May 2006 23:37:47 +0200 (CEST) Received: from [192.168.2.186] (catv-5062e7e3.catv.broadband.hu [80.98.231.227]) by server.t-hosting.hu (Postfix) with ESMTP id E23EF998F23; Mon, 15 May 2006 23:37:46 +0200 (CEST) Message-ID: <4468F4A7.9080205@t-hosting.hu> Date: Mon, 15 May 2006 23:37:43 +0200 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Julian H. Stacey" References: <200605151213.k4FCDcBm081238@fire.jhs.private> In-Reply-To: <200605151213.k4FCDcBm081238@fire.jhs.private> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: Running i386 binaries on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2006 21:37:55 -0000 Julian H. Stacey wrote: > =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= wrote: > >> Julian H. Stacey wrote: >> >>> gabor.kovesdan@t-hosting.hu wrote: >>> >>> >>>> either, you have to get the RELENG_6_1 >>>> >>>> >>> RELENG_6_1 is for stable beyond, which jim might not want, >>> to match release if uname -r == 6.1-RELEASE : RELENG_6_1_0_RELEASE >>> >>> >> RELENG_6_1 is *not* for stable, RELENG_6 is for stable. >> > > Yes. > (Tricky word stable, I know what you mean, but I've also > seen so called stable that was quite unstable on occasion > way back, when one was ill advised to track beyond fixes > for the specific release that was really `stable' in the > real normal non BSD sense of the word, not some > inter-release-hopefully-maybe-but-sometime-not-stable thing ;-) > > >> RELENG_6_1 is >> the security branch for 6.1-RELEASE, >> > > Yes. > (& thus more stable (in the real sense of the word) & > invariant than the inter-release progressive RELENG_6 that > FreeBSD names as 'Stable') > > >> this should be used instead of >> RELENG_6_1_1_RELEASE. >> > > "Could" Yes, "Should" No. Not always. It's a matter of personal > requirement that we are not qualified to dictate to others. Some > few people may _really_ _want_ exactly the release for their own > very good reasons eg QA stamped, part of embedded systems with > expected & tested & timed repose, relied on to interact exactly as > expected, or more bluntly, simply 'cos they've been told they'll > be fired & or imprisoned (eg if in military or high rel. sytems), > if they change an authorised code base without authority. > > > IMHO, that's a very special case. Aside from these kinds of licensing hurdles you mentioned as a special example, I still think that the security branch should be used. Only very slight changes go to RELENG_6_1 that don't cause functional changes. Using RELENG_6_1_0_RELEASE anyway is like buying a two-day bread instead of the fresh one. The security branch offers the same functionality and *quality* that the original release, so imho the other points you listed make no sense. I really don't want to flame about this, but I'm curious what others think about this topic, because I'm very convinced that the use of the release tag is strongly discouraged after the release. If a security hole is recognized why one might not want to patch it? Gabor Kovesdan