From owner-cvs-all@FreeBSD.ORG Thu May 29 07:50:25 2008 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 C75CC106566B; Thu, 29 May 2008 07:50:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 764018FC0C; Thu, 29 May 2008 07:50:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 74B7546C1F; Thu, 29 May 2008 03:50:24 -0400 (EDT) Date: Thu, 29 May 2008 08:50:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daniel Eischen In-Reply-To: Message-ID: <20080529084608.X39873@fledge.watson.org> References: <200805272004.m4RK4SZt029194@repoman.freebsd.org> <483C7FF2.6000607@FreeBSD.org> <483C977F.20105@delphij.net> <20080528060333.GA4699@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Maxim Sobolev , src-committers@freebsd.org, d@delphij.net, cvs-src@freebsd.org, cvs-all@freebsd.org, Xin LI , re@freebsd.org, David Schultz Subject: Re: cvs commit: src/include string.h src/lib/libc/string Makefile.inc memchr.3 memrchr.c src/sys/sys param.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: Thu, 29 May 2008 07:50:25 -0000 On Wed, 28 May 2008, Daniel Eischen wrote: > There's nothing technically wrong with it in that it will work, but for > minor features that provide low marginal utility, I'm not sure that it is > warranted. I would rather see the bar raised for new features added to > -stable branches. But I don't feel strongly enough one way or the other to > request a backout. I think there's actually a strong contrary argument to this in the general case: the things we should try hardest to MFC are the most trivial changes, as those changes have the lowest risk and highest utility in reducing gratuitous differences between branches. The more "minor" changes present in HEAD vs a RELENG_ branch, the harder it is to merge larger functional changes: there may be conflicting diffs, subtle dependencies, etc. I don't have any specific cases in mind for this particular function, but certainly in the network stack and elsewhere in the kernel, there is a strong motivation to merge quickly and frequently for minor changes so that they don't build up over time and make other, more important, changes harder to merge. The more we allow 8.x and 7.x to diverge, the harder it will be to bring back changes and keep the 7.x branch running in the long term, and the more likely it is that when we run into harder merges later. So, this is neither a vote for nor against a backout, but this is a general call to resist the conservative tendancy that says "don't MFC minor things" because, in macro, it has a significant drag effect on the MFC process that keeps RELENG branches maintainable. Robert N M Watson Computer Laboratory University of Cambridge