From owner-freebsd-current@FreeBSD.ORG Tue Oct 8 04:59:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 934006DB; Tue, 8 Oct 2013 04:59:31 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57E5D2274; Tue, 8 Oct 2013 04:59:31 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id at1so18641302iec.30 for ; Mon, 07 Oct 2013 21:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3emXRmQtP4eogjypNBquXSnQ5KgvrWjTIR8Qek+9d44=; b=SwNrYpkS4sAhSrnaLcIozsmFxXp8Gkk1XX5ds9xV1+a3Y2ViDJwIYdf44zbMxKhnMb 50SbTN6DbQhnJl1DyN4wBgarrSAxVYN148Mt6ejiLsV+E6JvtJppPH/KFwbM/MNxdw1z 6p8Q3Q5QIoZiaqJPJAw2y3RFsKRaYySu6J7wNyKk2svQl+iG8O0udsImmsHSSWfKmPBd 2x1CoVKtZx7k/3M3t3O1pI36FLA4/wKxKjNMFESjp4VJ+hZ0nn2lUfOlT4/H7XhsXjkb WjZ3xK5tySuSJYBuBj5Ei+JF0WCHLprjfnOeHonO7Jm0/lxKyNN6xmumHilvt600docH 0HuQ== MIME-Version: 1.0 X-Received: by 10.42.51.144 with SMTP id e16mr20177669icg.2.1381208370619; Mon, 07 Oct 2013 21:59:30 -0700 (PDT) Received: by 10.64.8.244 with HTTP; Mon, 7 Oct 2013 21:59:30 -0700 (PDT) In-Reply-To: <52538D19.8000505@freebsd.org> References: <20131007150658.GA79233@troutmask.apl.washington.edu> <52534B5E.7010401@freebsd.org> <20131008002854.GB56872@funkthat.com> <525354C2.8070807@m5p.com> <20131008013350.GB31261@troutmask.apl.washington.edu> <525364A8.6020300@freebsd.org> <52538D19.8000505@freebsd.org> Date: Tue, 8 Oct 2013 00:59:30 -0400 Message-ID: Subject: Re: [Heads Up] RCS removed from base From: Mehmet Erol Sanliturk To: Julian Elischer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: George Mitchell , freebsd-current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 04:59:31 -0000 On Tue, Oct 8, 2013 at 12:42 AM, Julian Elischer wrote: > On 10/8/13 12:34 PM, Mehmet Erol Sanliturk wrote: > > > > > On Mon, Oct 7, 2013 at 9:49 PM, Julian Elischer wrote: > >> On 10/8/13 9:33 AM, Steve Kargl wrote: >> >>> On Mon, Oct 07, 2013 at 08:41:38PM -0400, George Mitchell wrote: >>> >>>> On 10/07/13 20:28, John-Mark Gurney wrote: >>>> >>>>> Julian Elischer wrote this message on Tue, Oct 08, 2013 at 08:01 +0800: >>>>> >>>>>> not a big thing but I believe that a lot of poeple use ci/co on /etc >>>>>> becasue it is "just there" >>>>>> >>>>> +1 >>>>> >>>>> Folks, this is just plain a major violation of the Principle of Least >>>> Amazement. RCS is ideal for keeping track of my configuration files >>>> in /etc. What do we gain by removing it? >>>> >>> Less GPL code in FreeBSD? >>> >> not a problem unless you plan in shipping a changed version of it on your >> product?? >> >> > > Most new versions of GPL licensed code are converted to Version 3 GPL . > > This is blocking FreeBSD if they keep GPL licensed code in base , > because commercial companies usingFreeBSD are not able to use FreeBSD any > more if the FreeBSD switches to Version 3 GPL . > > This obstacle is in the base system GCC : It stayed in an older version > , and necessitated to switch to Clang/LLVM . > > Difficulty of such a switch is apparenly known . > Therefore cleaning base from GPL licensed code is a vital requirement > for further progress WITH RESPECT TO FreeBSD Project structure . > > Thank you very much . > > > sure but lets keep the one one in the the tree untill there is a > replacement ready to commit. ro 10 will have NO RCS which is a POLA. > > If we approach to the removal problem in the following way , I think such removals will be "transparent" for the users : Assume head iso is Head_A.iso , and it is installed as Head_A.system . We removed a feature and generated Head_B.iso , which installs a Head_B.system . Here Head_A.system and Head_B.system are NOT equivalent in functionality and therefore people should take additional steps to make them equivalent . For automated installs and upgrades this may cause much trouble for some users . Instead of doing the above removal in its present form , apply the following steps : In removal patch , include the following steps also : (1) Modify BSDinstall to install the removed part from ports already stored into CD/DVD . ( This will not require Internet or network connection during install and will be applied automatically . ) (2) Modify upgrade program/configurations to upgrade removed parts from ports . ( Since upgrade will use Internet and / or network , this will not be a problem ) . With the above additions , the new Head_B.iso and Head_B.system will be equivalent to the Head_A.iso and Head_A.system without causing any difficulty with the assumption that new functionality is tested sufficiently and is working correctly . In this way , no one will be affected because new system will not break anything . The nonexistence of the above steps is causing such a large controversy . Thank you very much . > > > Mehmet Erol Sanliturk > > > > > >