From owner-cvs-all@FreeBSD.ORG Mon Aug 27 15:18:42 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89F1216A421; Mon, 27 Aug 2007 15:18:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5201713C45D; Mon, 27 Aug 2007 15:18:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 6F1291A3C1A; Mon, 27 Aug 2007 07:56:18 -0700 (PDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Mon, 27 Aug 2007 10:41:21 -0400 User-Agent: KMail/1.9.7 References: <20070824215515.GF16131@turion.vk2pj.dyndns.org> <200708270850.20904.jhb@freebsd.org> <20070827135625.GF29854@garage.freebsd.pl> In-Reply-To: <20070827135625.GF29854@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708271041.23205.jhb@freebsd.org> Cc: src-committers@freebsd.org, alfred@freebsd.org, cvs-all@freebsd.org, deischen@freebsd.org, cvs-src@freebsd.org, Warner Losh , yar@comp.chem.msu.su Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 15:18:42 -0000 On Monday 27 August 2007 09:56:25 am Pawel Jakub Dawidek wrote: > On Mon, Aug 27, 2007 at 08:50:19AM -0400, John Baldwin wrote: > > On Friday 24 August 2007 07:22:12 pm Warner Losh wrote: > > > What's the overhead of having the transition crutch around for a > > > while? The benefit is that people are less likely to screw up their > > > systems at a time when we want to encourage people to upgrade so they > > > can test the latest/greatest version. If it were 9 months after > > > RELENG_6 was branched, and a long time to a release, then I'd be much > > > more inclined to agree with the 'current is hard, so why spend > > > engineering effort on making it easy' crowd than I would now that more > > > of the world is watching and using it since we're in the glide path to > > > beta1. > > > > > > I don't see why we can't put the versioned symbols in, let everybody > > > upgrade and then remove the old symbols after a big enough window has > > > passed. It isn't like they are hurting anything by being there, is > > > it? > > > > Then why didn't we bump libc multiple times in a branch? It's the same > > exact thing except more fine-grained. If it's ok to bump symbol > > versions multiple times (remember, we've already done 1 bump by adding > > versioning and going to libc.so.7) in a branch, then it should have been > > ok to bump libc major numbers multiple times. > > > > I agree with Dan that we are trying to build releases, and folks running > > -current are expected to tolerate change during the current branch. > > Folks running -current are also committers that use -current to test as > much as they can, but also to use it for day-to-day work. Isn't it why > we have perforce and other policies, so that -current can be stable and > usable? If we have tools that can help -current users to use the system > smoothly, I'm all for using them. I can't imagine taking yet another two > days and reinstalling all ports, just because -current users are not > important. Of course -current users know how to deal with things like > this, but that doesn't mean they have to if there is another way. > The more surprises like that one, the less -current users we will have, > which means the less testing. > If there will be a need for me to reinstall all the ports I'll choose > not to upgrade or downgrade to 6.x... My desktop and server at home run 6.x. Only my laptop and test machines run -current, and of those, only my laptop has a lot of ports and I just rebuild all the ports when I upgrade it over an ABI change. Test boxes for things like mysql, etc. don't necessarily need all of X or KDE, etc. installed, so rebuilding the ports on a test box generally shouldn't have but so much overhead. Perhaps a more useful discussion would be how can we use symbol versioning sanely to support this in the future? The fbsd.hack idea could work, but it doesn't work in this case because the existing binaries are already linked. One suggestion that could start with 8.0 could be this: - when bumping the version for a symbol in HEAD, instead of going from fbsd-X.Y to fbsd-X+1.0, put the new symbol as fbsd-current-X+1.0. You can keep bumping the symbol as fbsd-current-X+1.whatever for subsequent changes - when it's time to branch HEAD to RELENG_X+1, you then add fbsd-X+1.0 symbol versions for the current versions of all the bumped symbols, and remove all the fbsd-current-* versions and compat shims before the release (before the RELENG_X+1_0 branch in fact). The rule there being that no release should ever ship with visible fbsd-current-* symbol versions. You could even proactively drop older fbsd-current-* compat shims in HEAD after having them around for a while. -- John Baldwin