From owner-svn-src-head@FreeBSD.ORG Thu Mar 3 21:42:12 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 819EC106566C; Thu, 3 Mar 2011 21:42:12 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE558FC13; Thu, 3 Mar 2011 21:42:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LHI00D0K4AB9F00@smtpauth3.wiscmail.wisc.edu>; Thu, 03 Mar 2011 15:42:11 -0600 (CST) Received: from anacreon.physics.wisc.edu (anacreon.physics.wisc.edu [128.104.160.176]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LHI0059S4A58850@smtpauth3.wiscmail.wisc.edu>; Thu, 03 Mar 2011 15:42:06 -0600 (CST) Date: Thu, 03 Mar 2011 15:42:05 -0600 From: Nathan Whitehorn In-reply-to: To: Scott Long Message-id: <4D700B2D.1010003@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-14, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.3.213620, SenderIP=128.104.160.176 References: <201103021606.p22G6vou020460@svn.freebsd.org> <201103031209.43857.jhb@freebsd.org> <4D6FCE64.3010302@freebsd.org> <201103031432.36336.jhb@freebsd.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:1.9.2.14) Gecko/20110302 Thunderbird/3.1.8 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin Subject: Re: svn commit: r219181 - head/release X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:42:12 -0000 On 03/03/11 15:14, Scott Long wrote: > On Mar 3, 2011, at 12:32 PM, John Baldwin wrote: >> On Thursday, March 03, 2011 12:22:44 pm Nathan Whitehorn wrote: >>> On 03/03/11 11:09, John Baldwin wrote: >>>> On Wednesday, March 02, 2011 11:06:57 am Nathan Whitehorn wrote: >>>>> Author: nwhitehorn >>>>> Date: Wed Mar 2 16:06:57 2011 >>>>> New Revision: 219181 >>>>> URL: http://svn.freebsd.org/changeset/base/219181 >>>>> >>>>> Log: >>>>> Add additional release makefile for bsdinstall-based media, along with >>>>> support files. This does not change the default behavior of anything. >>>>> >>>>> To make bsdinstall-based media, pre-build world and GENERIC, then run >>>>> the release target in Makefile.bsdinstall. >>>> Are you planning on keeping the current 'make release' behavior of building a >>>> full chroot and doing a clean build in the chroot to build a release? That >>>> is, is 'Makefile.bsdinstall' just a temporary shortcut for building test >>>> releases or is that the final replacement for 'release/Makefile'? >>> It was intended (modulo memstick building, docs, and some miscellaneous >>> cleanup) to be the final replacement for release/Makefile. In my >>> experience, the automatic fetching, clean build, and chroot was a major >>> impediment to easily making installation media for users to test >>> patches. I figured that if people (e.g. re@) really want a totally clean >>> tree, checking one out by hand and building from there didn't seem like >>> an enormous obstacle. >>> >>> If you think it's a really important feature, I'm happy to add it back, >>> however. >> I think it is a very important feature to ensure release builds are not >> polluted by local changes in /etc/src.conf, etc. I think it would be good >> to support both models perhaps, but for our official release builds I think >> we need the clean environment. I certainly use 'make release' now for my >> own custom FooBSD builds to get a clean environment. >> > Agreed entirely. I'd consider it a major bug if the insulated release environment went away, especially since I'm switching release building at Yahoo to use it. There are plenty of shortcuts available in the script to reduce the time overhead for quick turnaround testing. To me, there's a distinction between "release building" and "make bootable media", and I like the suggestion to support both. One option would be that we keep the "make cdrom" target as is, but add dependencies, and then have a "release" target that actually the chroot setup. Another would be to keep the Makefile as-is, but to add a shell script that does the version control checkout, building, chroot setup, etc., etc. Would you have a preference there? -Nathan