From owner-freebsd-current@FreeBSD.ORG Thu Oct 11 12:34:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE78B16A41B for ; Thu, 11 Oct 2007 12:34:53 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mx1.netclusive.de (mx1.netclusive.de [89.110.132.131]) by mx1.freebsd.org (Postfix) with ESMTP id 60B0113C4BA for ; Thu, 11 Oct 2007 12:34:52 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (Fdd69.f.ppp-pool.de [195.4.221.105]) (Authenticated sender: ncf1534p2) by mx1.netclusive.de (Postfix) with ESMTP id 5D222DE80B2 for ; Thu, 11 Oct 2007 14:34:49 +0200 (CEST) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id AF0BB15217; Thu, 11 Oct 2007 14:27:04 +0200 (CEST) To: freebsd-current@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.current Date: Thu, 11 Oct 2007 14:27:04 +0200 (CEST) Organization: Convenimus Projekt Lines: 42 Message-ID: References: <86przndoe8.fsf@ds4.des.no> <20071010231643.GF58929@over-yonder.net> NNTP-Posting-Host: sunny.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1192105624 93945 192.168.100.5 (11 Oct 2007 12:27:04 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Thu, 11 Oct 2007 12:27:04 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD/6.2-RELEASE-p8 (sparc64)) Subject: Re: suggest renaming and extending the -CURRENT and -STABLE lines X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2007 12:34:53 -0000 On Thu, 11 Oct 2007 01:58:51 +0200 Ivan Voras wrote: > Unfortunately (for this developer-centric practice), the trend in large > and/or important production environments is - as seen in Linux (and > Solaris) - to severely limit major OS upgrades. I don't really see what's so unfortunate about that. Most admins (including myself) go by the rule "If it ain't broken, don't fix it!" Production systems, especially in companies are there to do something, and that is not trying out the latest new gadgets out there. In my company, out database server is *very* important and although downtime would not cost us any money off hand, we wouldn't be able to serve our customers anymore, since the information stored in there actually is the service we provide. I am very careful about trying out everything new out there, because every update bears the risk of downtime. And both -STABLE, but especially -CURRENT have risks of that sort. > Of course the existing possibility to do is excellent, but more and more > end-users, especially big ones, are going with big Linux distributions > that basically stay frozen (except for security upgrades) for years. And > this idea gets a +1 from me - productions releases that are expected to > run for years should be able to "just work" without upgrading to the > "kernel of the week". To do this, a stable anchor-point is required and > that's what -RELEASEes should be for. I think the fact that not all our > -RELEASES are created equal (some are "extended support" releases) > should be more advertised and explained. I'm not even sure we should board that train completely. Basicly, RELENG_x_y is just that, but is could also be a good idea to have and alternative. Something that is stable but can still be updated. Usually, an update from one release to the next is relatively painless (major releases excluded). I kept a machine running on RELENG_4 from 4.0-RELEASE until now without ever having to change or reinstall the packages on it. So it is possible. The next step would be to have something that updates like RELENG_x but only uses tested and stable code like RELENG_x_y without confining the user to a single release. Regards Chris