From owner-cvs-all@FreeBSD.ORG Wed May 28 00:37:47 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 559001065672; Wed, 28 May 2008 00:37:47 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 061498FC1B; Wed, 28 May 2008 00:37:46 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.40] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m4S0bSw8027549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 May 2008 17:37:30 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <483CA944.4050800@FreeBSD.org> Date: Tue, 27 May 2008 17:37:24 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: d@delphij.net References: <200805272004.m4RK4SZt029194@repoman.freebsd.org> <483C7FF2.6000607@FreeBSD.org> <483C977F.20105@delphij.net> In-Reply-To: <483C977F.20105@delphij.net> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Xin LI , re@FreeBSD.org, cvs-all@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-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: Wed, 28 May 2008 00:37:47 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Maxim Sobolev wrote: > | Xin LI wrote: > |> delphij 2008-05-27 20:04:27 UTC > |> > |> FreeBSD src repository > |> > |> Modified files: (Branch: RELENG_6) > |> include string.h lib/libc/string > |> Makefile.inc memchr.3 sys/sys param.h Added > |> files: (Branch: RELENG_6) > |> lib/libc/string memrchr.c Log: > |> MFC: Add memrchr(3). > | > | I think this is not very good idea to MFC that into stable releases 6.x > | and 7.x. The reason is that configure scripts for some packages might > | detect up this API and enable it. Which means that some binary-only > | packages build for say 6.4 won't work on 6.3 and down. AFAIK, both > | forward and backward compatibility is required (or at least desired?) > | for stable branches. > | > | While it's "nice-to-have" feature, I see no pressing need to MFC this > | interface. > > I don't think so, perhaps I am wrong, but do we really want absolutely > no *new* features on -STABLE branches? I think this case is different > from ctype(3) fix which is widely used API and a change of existing > interface by adding new dependency to a symbol that is not exist in the > older FreeBSD releases. It will really scare me away from any new > features if we can not add an new interface in RELENG_* trees even if > they have no outside dependencies, if that's the policy of ABI > compatibility guidelines then I'd be happy to revert these MFC's, but > having something can only run on -CURRENT does not sound like a good > idea, and maintaining in-tree alternative patches for different branches > for such things is really painful and will likely reduce the lifespan of > given -STABLE branches, is these our goal and should be kept in mind > when maintaining code in RELENG_* branches? Well, as I said it might not be something strictly required, but why not be nice to ISVs and users? Ability to run binaries compiled on 6.4 on previous 6.x releases is really important in many situations. The less gratuitous breakage we introduce the better. And yes, I know that historically we as a projects have had a very bad track record in this area. That's probably one of the reasons why big software vendors (Oracle, Sun etc) are very reluctant to provide native binary packages for FreeBSD. In this particular case the memrchr() is not something mandated by the C90 and/or POSIX/SUS. It's glibc extension. Any software that is portable should be able to live without it. IMHO, there is very little or no gain in having it MFCed. -Maxim