Date: Tue, 19 Apr 2011 12:04:53 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: Doug Barton <dougb@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, Roman Divacky <rdivacky@freebsd.org>, Dimitry Andric <dim@freebsd.org>, 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... Message-ID: <6ED7B30B-B545-4E38-A157-5008A1615DBC@bsdimp.com> In-Reply-To: <201104190840.29535.jhb@freebsd.org> References: <201104172103.p3HL3Ntb049564@svn.freebsd.org> <4DAC8060.2070002@FreeBSD.org> <92422863-8655-4FDE-A1E9-5EE1F46DA5BC@bsdimp.com> <201104190840.29535.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6ED7B30B-B545-4E38-A157-5008A1615DBC>