From owner-freebsd-amd64@FreeBSD.ORG Tue May 16 10:38:18 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 2044D16A40A for ; Tue, 16 May 2006 10:38:18 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70DB943D49 for ; Tue, 16 May 2006 10:38:17 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A63B9.dip.t-dialin.net [84.154.99.185]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id k4GAcE7V059072; Tue, 16 May 2006 12:38:15 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id k4GAcClV013314; Tue, 16 May 2006 12:38:13 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.1/8.13.1) with ESMTP id k4GAe5An093400; Tue, 16 May 2006 12:40:05 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200605161040.k4GAe5An093400@fire.jhs.private> To: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= In-Reply-To: Message from =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= of "Mon, 15 May 2006 23:37:43 +0200." <4468F4A7.9080205@t-hosting.hu> Date: Tue, 16 May 2006 12:40:05 +0200 From: "Julian H. Stacey" 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: Tue, 16 May 2006 10:38:18 -0000 > IMHO, that's a very special case. Aside from these kinds of licensing Not 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? NO ! The original questioner has read what we're agreed the tags will deliver. He's informed, We're Done - Finished ! Expounding what tags all should use, would be arrogance in ignorance: Not all systems are trivial, some have Strict code control authorisation procedures: eg a warship system that embeds DOS, Win-XP & Linux - Shudder!, BSD systems that get used in other `interesting' places. Firewall manufacturers integrating BSD. Less stringent applications like banking will also have managers who must sign off before _Any_ code change is allowed. Which CVS tags you urge is Not amd64 specific, so to discuss it, please on an all architectures list, eg chat@ -- Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com