From owner-freebsd-stable@FreeBSD.ORG Tue May 2 05:04:44 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A17AD16A400; Tue, 2 May 2006 05:04:44 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A1C043D46; Tue, 2 May 2006 05:04:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k4254MqD036652; Mon, 1 May 2006 23:04:22 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4456E860.8090308@samsco.org> Date: Mon, 01 May 2006 23:04:32 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <4456C439.1070500@samsco.org> In-Reply-To: <4456C439.1070500@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Mikhail Teterin , Paul Allen , current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 05:04:44 -0000 I tend to get snippy towards the end of release cycles, and I apologize to those I've offended or have been needlessly rude to. But please hear me out on what I have to say here.... What makes a release cycle stressful is not the bug tracking and fixing, or the building of bits, or anything like that. It's that many people seem to wait until the very last minute to test the release and speak up with their issues. I don't know if it's because people politely assume that all of the issues are already known and are being worked on, therefore their effort and their voice isn't needed, or if it's because people are reluctant to test anything until others have worked the bugs out for them. Either way, whether I try to rush a release in 1 month or let it draw out to 3 months, there is always the last minute push by those who are concerned about a certain problem or a missing feature and who desperately hope that something will be done about it. First of all, each release is a step in the overall process. While it's always unfortunate and undesirable to have bugs in releases or have missing features, it's even more undesirable to hold releases indefinitely until "all the problems are solved". It amounts to throwing away all of the work has happened on the hopes that future work might happen. Releases need to happen, and they need to happen on a regular basis. If something is broken or missing in a release, then it can be worked on in the next release. 6.1 is just a precursor to 6.2, and 6.2 can't happen until 6.1 is released. Second, we need more people testing early on in the release process. The BETA builds are meant to give people a baseline of what the expected functionality should be so that bugs can be found and fixed. The RC's are just meant to be a final polishing of cosmetic things. Waiting until RC1 or RC2 to test UFS quotas or ask why 32-bit compiling doesn't work is a bit late. If these things had been brought up 3 months ago, or even 1 month ago, there is a much higher probability that they could have been addressed. If no one wants to do any serious testing (with the notable exception of Kris Kenneway, Peter Holms, and a few others), then I might as well just skip the majority of the release cycle and just stamp out RC1 followed immediately by RELEASE. The release cycle doesn't work if people put off testing until others test for them. So please, when 6.2-BETA2 happens, everyone reading this email please give it a spin, even if it's just in a QEMU or VMWare session (and it is rediculously easy to test a CD with those, I do it all the time for my day job). The release process is about balancing the need to "get it done" with the need to "get it as good as possible". The time to identify and fix problems is during the BETA phase, so please help us to make that happen. And if we get to the RC phase and something is broken or unfinished, then please help us to get it resolved for the next release. Thanks, Scott