Date: Wed, 28 May 2008 09:55:41 -0400 From: Ken Smith <kensmith@cse.Buffalo.EDU> To: d@delphij.net Cc: Maxim Sobolev <sobomax@FreeBSD.ORG>, src-committers@FreeBSD.ORG, re@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Xin LI <delphij@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 Message-ID: <1211982941.57965.8.camel@bauer.cse.buffalo.edu> In-Reply-To: <483C977F.20105@delphij.net> References: <200805272004.m4RK4SZt029194@repoman.freebsd.org> <483C7FF2.6000607@FreeBSD.org> <483C977F.20105@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-4tXbilFueFXGh9jP5CRL
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Tue, 2008-05-27 at 16:21 -0700, Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> 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.
>=20
> 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?
I'm inclined towards letting this stay in. The ctype(3) fix altered an
existing interface in a way that made it incompatible with older stuff.
This is adding new stuff.
The "forwards compatibility" is a good thing for people trying to use
pre-built packages on older systems but this one is a case of us trying
to avoid breakage that, if it were to occur, would be at the whims of
the configure script for the packages. I think that's pushing the
notion of forwards compatibility a tiny bit too far.
--=20
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
--=-4tXbilFueFXGh9jP5CRL
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQBIPWRV/G14VSmup/YRAnt6AKCDcCl8KrjnwnQi5+RasJk7Sn9NnQCfUwpG
QVUybAgcoDGxBCGLnjp9VZA=
=lIl7
-----END PGP SIGNATURE-----
--=-4tXbilFueFXGh9jP5CRL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1211982941.57965.8.camel>