Date: Fri, 8 May 2015 13:59:47 -0700 From: Davide Italiano <davide@freebsd.org> To: Pedro Giffuni <pfg@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>, NGie Cooper <yaneurabeya@gmail.com>, Lyndon Nerenberg <lyndon@orthanc.ca> Subject: Re: What to do about RCS/OpenRCS Message-ID: <CACYV=-F5RUVNmhqX13=EndiZhKPMSgp93QjWVJx2QZn1zMbTyA@mail.gmail.com> In-Reply-To: <554D1DD5.5080106@FreeBSD.org> References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> <CAGHfRMAc4XwqME8Nmi05oy1HBWZZTGLsWoXwkQw3W542GCZB1g@mail.gmail.com> <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 8, 2015 at 1:34 PM, Pedro Giffuni <pfg@freebsd.org> wrote: > Hi; > > >> I guess I see the following options: >> >> 1) Just leave GNU RCS in the tree. >> >> 2) Improve OpenRCS so it can be swapped in. >> >> 3) Remove RCS dependencies from other parts of the tree (e.g. >> etcupdate) >> and import just a /bin/ident binary (perhaps from OpenRCS). >> >> Both 2) and 3) require some work. I suspect 3) requires less. :) > > > I honestly don't see a real problem with (1): we do want to replace as much > GNU > software as we can but not at the cost of making our life unnecessarily > difficult. > To be honest I'm not entirely sure what's the real reason of this crusade. FreeBSD can't import newer version of some components of the toolchain (e.g. compiler, linker, debugger) and some of them are slowly (or less slowly) bitrotting. I feel that in that case there's a real goal which justifies all the headache derived from the conversion. For GNU RCS, I'm not completely sure there is. I've never heard anybody complaining about lack of features for RCS or bugs. My $0.02, I suspect very few people really rely on it and just complain for the sake of doing it, but I'm not gonna argue on this further. That said, unfortunately there's a lot more than doing the conversion and fixing the code so that the testsuite will pass. You need to upstream the fixes and so deal with another layer and other maintainers otherwise the code in base and the one upstream will diverge. People rely from time to time on bugs of old software (e.g. single vs double dash options) and are gonna complain. The testsuite, even if comprehensive, unlikely will cover some corner cases and suddenly software will start breaking. In other words, a lot of (unneeded) work for you for a software that just worked fine(TM) until yesterday. I'm not gonna stop you from doing this, but I learned the hard way that it's something that can/should be avoided unless really necessary (and a better license doesn't seem to be a strong enough reason, IMHO). -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACYV=-F5RUVNmhqX13=EndiZhKPMSgp93QjWVJx2QZn1zMbTyA>