From owner-cvs-src@FreeBSD.ORG  Thu May 29 15:21:41 2008
Return-Path: <owner-cvs-src@FreeBSD.ORG>
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 9B4111065676;
	Thu, 29 May 2008 15:21:41 +0000 (UTC)
	(envelope-from deischen@freebsd.org)
Received: from mail.netplex.net (mail.netplex.net [204.213.176.10])
	by mx1.freebsd.org (Postfix) with ESMTP id 1B7268FC17;
	Thu, 29 May 2008 15:21:40 +0000 (UTC)
	(envelope-from deischen@freebsd.org)
Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11])
	by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id
	m4TFLVDJ010743; Thu, 29 May 2008 11:21:31 -0400 (EDT)
X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net)
X-Greylist: Message whitelisted by DRAC access database, not delayed by
	milter-greylist-4.0 (mail.netplex.net [204.213.176.10]);
	Thu, 29 May 2008 11:21:32 -0400 (EDT)
Date: Thu, 29 May 2008 11:21:31 -0400 (EDT)
From: Daniel Eischen <deischen@freebsd.org>
X-X-Sender: eischen@sea.ntplx.net
To: Robert Watson <rwatson@freebsd.org>
In-Reply-To: <20080529084608.X39873@fledge.watson.org>
Message-ID: <Pine.GSO.4.64.0805291106120.12774@sea.ntplx.net>
References: <200805272004.m4RK4SZt029194@repoman.freebsd.org>
	<483C7FF2.6000607@FreeBSD.org> <483C977F.20105@delphij.net>
	<20080528060333.GA4699@zim.MIT.EDU>
	<Pine.GSO.4.64.0805281049150.7240@sea.ntplx.net>
	<20080529084608.X39873@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Maxim Sobolev <sobomax@freebsd.org>, src-committers@freebsd.org,
	d@delphij.net, cvs-src@freebsd.org, cvs-all@freebsd.org,
	Xin LI <delphij@freebsd.org>, re@freebsd.org,
	David Schultz <das@freebsd.org>
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-src@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Daniel Eischen <deischen@freebsd.org>
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 29 May 2008 15:21:41 -0000

On Thu, 29 May 2008, Robert Watson wrote:

>
> 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.

Ok, but consider the prior email with kan about MFC's after an 8.0
release.  Since you must be able to run 7.x binaries on 8.0, then
you can't MFC any symbol changes from 8.0+ back to 7.x.  The symbols
are basically frozen in 7.x after 8.0 is released.

We could sidestep this issue a little if the symbols were also MFC'd
to the 8.0 release branch and prohibit our base system from using
them.  Or by waiting until 8.1 was released before MFC'ing to 7.x
so there would be a compatible upgrade path.  Or say that compatibility
goes by release _date, not by version number...

-- 
DE