From owner-svn-src-all@FreeBSD.ORG Tue Apr 19 18:13:47 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 0D7751065672; Tue, 19 Apr 2011 18:13:47 +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 975788FC16; Tue, 19 Apr 2011 18:13:46 +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 p3JIA41B060108 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 19 Apr 2011 12:10:05 -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: <201104191129.30602.jhb@freebsd.org> Date: Tue, 19 Apr 2011 12:09:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2B6A971D-432F-4330-9BAB-48CAE89FF571@bsdimp.com> References: <201104172103.p3HL3Ntb049564@svn.freebsd.org> <201104190840.29535.jhb@freebsd.org> <201104191129.30602.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:10:06 -0600 (MDT) Cc: svn-src-head@freebsd.org, mdf@freebsd.org, svn-src-all@freebsd.org, src-committers@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:13:47 -0000 On Apr 19, 2011, at 9:29 AM, John Baldwin wrote: > On Tuesday, April 19, 2011 10:28:23 am mdf@freebsd.org wrote: >> Trimming since I have a mostly-unrelated question... >>=20 >> On Tue, Apr 19, 2011 at 5:40 AM, John Baldwin = wrote: >>> On Monday, April 18, 2011 3:59:45 pm Warner Losh wrote: >>>> In this case, there was a new kernel thing just after, so it turned = out OK. >>>> But let's not gratuitously bump the version since the granularity = we have >>>> already allows the ports to make good choices on when to leave = something in or >>>> out. >>>=20 >>> Except that that directly contradicts our previously established = policy that >>> these version bumps are cheap and that we should do more of them = (this came up >>> a few years ago when we changed the policy so that the new "stable" = branch >>> after a release starts at N + 500 (e.g. 802500) rather than N + 100 = to give >>> more room for version bumps on current). >>=20 >> I thought I remembered reading (within the past 2 years) that >> __FreeBSD_version should not be incremented more than once a day, >> since there was a limit of 100 before the version minor number was >> affected. Did I get the polarity backwards and that was the old >> policy? >=20 > Well, I would avoid more than once a day still, but the 100 limit is = now 500 > in 8.0 and later (we had more than 100 bumps during 8.0-current which = resulted > in a discussion where we chose to raise the limit to 500 rather than > discourage bumps in current). There were times in the 8.x release train when I got hit by this problem = a lot. I'd update to get a fix in some other part of the tree, and = there's be another bump even though I had compiled a kernel just hours = before. While I can live it it from time to time, there was a stretch = where it happened to me all the time and it wound up costing me a = substantial portion of a working week. It is all about windows. If there's a small window since the last bump, = please biggy back on it. If there isn't, by all means bump. I'd tune = small measured in days rather than a single day, since it is rare that = ports need to know with such precision when something happened and small = windows tend to impact fewer people than the bumps do. Warner=