Date: Sat, 09 May 2015 10:05:05 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Davide Italiano <davide@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: <554E2221.1040105@FreeBSD.org> In-Reply-To: <CACYV=-F5RUVNmhqX13=EndiZhKPMSgp93QjWVJx2QZn1zMbTyA@mail.gmail.com> References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> <CAGHfRMAc4XwqME8Nmi05oy1HBWZZTGLsWoXwkQw3W542GCZB1g@mail.gmail.com> <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <CACYV=-F5RUVNmhqX13=EndiZhKPMSgp93QjWVJx2QZn1zMbTyA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/08/15 15:59, Davide Italiano wrote: > 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. Having a consistent license for all the OS has important advantages. The main principle is that while we are fine about sharing and having other people re-use our code we don't really want to have to check with a lawyer before taking any decision. Some years ago, this was basically impossible due to the toolchain, now it seems possible although it certainly requires more work. > 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. I think there are legitimate reasons for having it in base. > 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. We do that with GNU code anyways. The latest (GPLv3) version of RCS has already diverged and is incompatible for some third party software so we basically ran out of support from upstream. OpenRCS has it's own share of problems but generally we can work with the OpenBSD maintainers to get things to improve. I think I found the issue at hand and the code has an /* XXX: This is wrong ... */ Which doesn't really get me nearer to a solution but at least upstream knows where to look. We can wait. > 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). > No one (or at least not me) is going to replace GNU RCS with something of considerable less quality just for the license. Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?554E2221.1040105>