From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 15:46:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D05F16A4CE for ; Mon, 8 Nov 2004 15:46:50 +0000 (GMT) Received: from avas7.globetrotter.net (smtp2.globetrotter.net [142.169.1.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 332D143D53 for ; Mon, 8 Nov 2004 15:46:49 +0000 (GMT) (envelope-from freebsd-current@sfina.com) Received: from smtp2.telusquebec.local(192.168.250.24) by avas7.globetrotter.net via csmap id f0c34206_319c_11d9_91de_0002b3a434af_5187; Mon, 08 Nov 2004 10:43:31 -0500 (EST) Received: from avas7.globetrotter.net (c207.134.17-22.clta.globetrotter.net [207.134.17.22]) by smtp2.globetrotter.net (iPlanet Messaging Server 5.2) with SMTP id <0I6V00875AHZQV@"TELUS Quebec"> for freebsd-current@freebsd.org; Mon, 08 Nov 2004 10:46:48 -0500 (EST) Received: from c207.134.17-22.clta.globetrotter.net(207.134.17.22) by avas7.globetrotter.net via csmap id efc3473e_319c_11d9_8949_0002b3a434af_5166; Mon, 08 Nov 2004 10:43:29 -0500 (EST) Date: Mon, 08 Nov 2004 10:48:09 -0500 From: Yuval Levy In-reply-to: <200411061819.05364.msch@snafu.de> To: freebsd-current@freebsd.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: RE: FreeBSD 6.0 and onwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 08 Nov 2004 15:46:50 -0000 > We are still debating the exact time line, but it will fall somewhere > between doing a new -STABLE branch every 12-18 months, and doing point > releases every 4-6 months. Hi all, First thank you all for the tremendous effort and passion that you put into FreeBSD. You guys are doing a great job! As potential user I have been following your project from the sideline for a year and decided to migrate from Red Hat Linux to FreeBSD when 5.x becomes production grade. It will happen soon. I am a small business and a migration is big headache; a drain on ressources and time; unnecessary risk. The least I have to migrate, the better. This conservative attitude conflicts with the progressive nature of technology (and my own personal attitude). IMHO FreeBSD has good tools (CVS) and excellent management processes to deal with the conflict. This was the most important factor to my decision. Not all migrations are bad: While I prefer to avoid big disruptive changes (such as from 4.x to 5.x), I appreciate progressive, smooth, incremental evolution through many little steps. Without knowing the details a change from 5.x to 6.x sounds like disruption to me. Disrupting too often will turn users like me away. As a business I need predictability. I love the idea expressed by Scott earlier of regular, frequent releases. I'd go one step further: Rather than declaring the CURRENT branch STABLE and open a new CURRENT branch, I would suggest to let both branches grow indefinitely with STABLE playing catch-up on CURRENT. All changes (including major changes such as API) implemented incrementally rather than disruptively and with a painless upgrade path from one STABLE version to the next as the recommended way of keeping production environments alive and secure. As a naming convention I'd suggest STABLE-yyyyxx (where yyyy is the year and xx is an incremental counter reset at the beginning of each year) and CURRENT-yyyyxx. Upgrading is of critical importance. My wish is for and automated upgrade path from one STABLE release to the next that can be applied remotely. Upgrading from STABLE-200401 (4.10) to the next STABLE-200402 (5.3) should not be more difficult than upgrading from STABLE-200302 (4.9) to STABLE-200401(4.10). If it is, maybe it is worth to split the new features over several releases and increase release frequency - a decision for the release engineering team. As long as the upgrade path is easy and tested, I would not mind even a monthly release schedule (meaning that there are less changes between releases). A higher release frequency should not mean more work for the security team. As a rule, only the latest STABLE and CURRENT releases should be supported with patches. The standard recommendation would be "upgrade to the latest STABLE" and patch on from there if necessary. Only in exceptional cases a STABLE release should be declared "milestone" and supported by the security team beyond the next STABLE release for as long as deemed necessary - a negotiated decision between the security team and the project leader based on community input, technological progress and available ressources. In terms of development, new/changed components would start their life on the CURRENT branch as today. Once the component is ready for prime time, it is ported to the STABLE branch and released with the next regular release. >From my (limited) user perspective and measured by the tangible results, the current CVS tools seem more than adequate. If it ain't broke, don't fix it! Your project is probably the best managed operating system development in the world and you have all reason to be proud of your achievements. Honestly, as a user I don't care much what tool you use to keep track of changes as long as the tools delivers. It is like a car: drive me from A to B and I'll be happy, no matter what make or model it is. What I do care about is the quality of the end product and you guys provide a top class product with the tools at hand! Thanks again for the good job! Yuval Levy