On 05/08/15 15:59, Davide Italiano wrote:
On Fri, May 8, 2015 at 1:34 PM, Pedro Giffuni <p...@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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to