From owner-cvs-src@FreeBSD.ORG Tue Aug 28 18:03:41 2007 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B361416A418; Tue, 28 Aug 2007 18:03:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 22B7C13C4CB; Tue, 28 Aug 2007 18:03:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8k2) with ESMTP id 205829202-1834499 for multiple; Tue, 28 Aug 2007 14:03:48 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l7SI3MSc040032; Tue, 28 Aug 2007 14:03:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Daniel Eischen Date: Tue, 28 Aug 2007 14:03:04 -0400 User-Agent: KMail/1.9.6 References: <200708270850.20904.jhb@freebsd.org> <200708281142.07941.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708281403.05931.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 28 Aug 2007 14:03:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4088/Tue Aug 28 07:51:32 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: src-committers@freebsd.org, peterjeremy@optushome.com.au, Yar Tikhiy , alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 18:03:41 -0000 On Tuesday 28 August 2007 01:18:38 pm Daniel Eischen wrote: > On Tue, 28 Aug 2007, John Baldwin wrote: > > > > I think this is dead on, yes. Only comment I would add is that I think > > the "flag days" should be when a new RELENG_X is branched and that all the > > FBSD-current shims get tossed in the RELENG_X branch. The FBSD-current shims > > can be dropped from HEAD on a separate schedule, maybe where they get dropped > > after they've been around for 6 months or so. This does mean that stepping > > off -CURRENT onto RELENG_X requires a rebuild of your ports for any symbols > > that changed since RELENG_X-1, but I think that is tolerable. > > The only thing I would add is that we can do this by using the > real public versions in -current instead of private ones only > seen in current. By using the public versions, -current users > will never have to rebuild any of their ports _unless_ the > same ABI changed more than once in -current, and that has > never happened in the past. If it does happen, you can > remove interim versions from RELENG_X at the branch, and > then remove the interim version from -current some time later. > This is the same approach as using a "private in current" > version namespace. The only disadvantage is that you might > be missing a version or two in RELENG_X if you remove an > interim FBSD_1.4 for instance. Yes, but how do you know which ones are interim versions that are safe to be removed? Having separate namespaces makes this clear. > The other problem with the private version namespace thing > is that it doesn't allow for MFC'ing an ABI change to RELENG_X. > It also causes you to change a lot of files (Symbol.map files, > source files with compat shims) whenever you have the flag > day and move from FBSDcurrent_1.x to FBSD_1.1. You can manage the MFC by making the symbol a "public" symbol and then MFC'ing it into the public namespace. Changing a lot of files is a true point. > It is so much more simpler to use the same versioning in > -current as for releases. It is easier to MFC, doesn't > cause unneeded changes to Symbol.map files and compat shims, > doesn't cause -current users to rebuild ports after flag > day (unless there are overlapping ABI changes), and still > provides everything that using the private version namespace > provides. Note that if you stick on HEAD you won't have a flag day, the flag change is on the RELENG_x branch, so only if you are following HEAD and decide to follow the new RELENG_x branch rather than staying on HEAD do you have a flag day. That is, if one did a bump to foo@fbsd-current-1.0.1 a week before RELENG_12 was branched, then at the time of the branch, foo@fbsd-current-1.0.1 gets "tagged" as foo@fbsd-1.1, then in the branch foo@fbsd-current-1.0.1 label gets dropped, but in HEAD the foo@fbsd-current-1.0.1 label might stick around for 4 months. The one thing that the simpler case doesn't provide is a clear delineation between "extra" versions in the case that one does multiple ABI bumps in HEAD. This really hinges on how often we expect that to happen I guess. If we (collectively) don't expect it to be often, perhaps then the simple policy (just use the real versions always, and bump for everything, including this fts(3) change) can be used for now, and if we find at some point that we do have a lot of extra versions we can then revisit the policy. Also, one variation based on what Yar said earlier that I hadn't thought of, is that we could use fbsd-X.Y.Z as the "private" versions for HEAD if one did use the more complicated scheme. Anyways. -- John Baldwin