From owner-svn-src-all@FreeBSD.ORG Tue Apr 19 18:06:21 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58F37106564A; Tue, 19 Apr 2011 18:06:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1978D8FC0C; Tue, 19 Apr 2011 18:06:21 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p3JI4xPx060074 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 19 Apr 2011 12:05:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201104190840.29535.jhb@freebsd.org> Date: Tue, 19 Apr 2011 12:04:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6ED7B30B-B545-4E38-A157-5008A1615DBC@bsdimp.com> References: <201104172103.p3HL3Ntb049564@svn.freebsd.org> <4DAC8060.2070002@FreeBSD.org> <92422863-8655-4FDE-A1E9-5EE1F46DA5BC@bsdimp.com> <201104190840.29535.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 19 Apr 2011 12:05:03 -0600 (MDT) Cc: Doug Barton , Pawel Jakub Dawidek , Roman Divacky , Dimitry Andric , src-committers@freebsd.org, svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r220755 - in head: . contrib/gcc/doc contrib/gcc/objc contrib/libobjc etc/mtree gnu/lib gnu/lib/libobjc gnu/usr.bin/cc gnu/usr.bin/cc/cc1obj gnu/usr.bin/cc/cc_tools gnu/usr.bin/cc/doc s... X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:06:21 -0000 On Apr 19, 2011, at 6:40 AM, John Baldwin wrote: > On Monday, April 18, 2011 3:59:45 pm Warner Losh wrote: >>=20 >> On Apr 18, 2011, at 12:18 PM, Doug Barton wrote: >>=20 >>> On 04/18/2011 11:14, Pawel Jakub Dawidek wrote: >>>> On Mon, Apr 18, 2011 at 11:06:42AM -0600, Warner Losh wrote: >>>>>=20 >>>>> On Apr 18, 2011, at 1:01 AM, Roman Divacky wrote: >>>>>=20 >>>>>> please mark this in src/UPDATING, maybe bump freebsd_version too? >>>>>=20 >>>>> Please do not bump freebsd_version just for this. Ports wishing = to know=20 > can go off the last bump, if there are any. >>>>>=20 >>>>> Every freebsd_version bump forces rebuilding all modules and such = and is=20 > a pita. >>>>=20 >>>> I agree that this is a PITA, but there also should be a way to = force >>>> module load even on version bump. This is PITA especially for >>>> developers. >>>=20 >>> .... who make up a tiny percentage of the FreeBSD user community.=20 > Seriously? We're going to whine because version bumps cause a little = extra=20 > compile time? >>=20 >> The problem usually manifests itself when I got to debug a new = problem, load=20 > a driver and find I have to rebuild everything else to use it, which = forces an=20 > extra reboot on the machine in question. Sometimes this can be quite=20= > disruptive to other things that machine is doing. >=20 > But that is only true if your source tree doesn't match your installed = world. =20 > If the new driver is standalone and you build it as a module, it will = use the=20 > headers from /sys and will work fine. It is rarely the case that my source matches my install world. My = kernel and userland are asynchronously updated when I'm doing heavy = kernel development. My sources are updated all the time to pull in = useful things that I need. When I'm in this mode, I carefully track = what's changed to make sure there were no recompile the world events. = When a userland thing changes that bumps freebsd_version, I have to = recompile the kernel and reboot, even though there's no need to do so. = This is especially annoying when it happens a few times within one week, = since it is a hit to my productivity each time it happens. There's no = great need to have userland features identified with the fidelity of a = few dozen commits in -current. A few hundred or more would suffice for = ports and those interested, so bumping more than once a week provides = almost no benefit, but inflicts some pain. > If the new driver is part of the source tree, you do not have to = upgrade the=20 > entire world, just build a kernel + moduleset, install that to = /boot/foo and=20 > reboot into the foo kernel. Yes, that can require a reboot, but lots = of=20 > kernel development requires reboots. Just because sometimes a reboot might be required doesn't mean that = forcing a reboot is necessary. >> In this case, there was a new kernel thing just after, so it turned = out OK. =20 > But let's not gratuitously bump the version since the granularity we = have=20 > already allows the ports to make good choices on when to leave = something in or=20 > out. >=20 > Except that that directly contradicts our previously established = policy that=20 > these version bumps are cheap and that we should do more of them (this = came up=20 > a few years ago when we changed the policy so that the new "stable" = branch=20 > after a release starts at N + 500 (e.g. 802500) rather than N + 100 to = give=20 > more room for version bumps on current). We have never said that version bumps were totally cheap. In -current, = there's little benefit to bumping things more often than once a week. = Since we generally develop stable for more than 2 years, 100 wasn't = enough at the one a week rate. But that doesn't mean that 5 per week is = OK either, since now we suddenly have room for them. I'm strongly = suggesting that for userland-only changes that one check to see when the = last bump was and if it is less than a few days (or a week), then to = piggyback off the last one/next one to discriminate whether to use an = old feature, or start using a new feature. Especially for retroactive = bumps that happen disconnected to the original feature going in. Warner=