[Heads Up] RCS removed from base

[Mehmet Erol Sanliturk]

On Tue, Oct 8, 2013 at 12:42 AM, Julian Elischer <julian at freebsd.org> wrote:

>  On 10/8/13 12:34 PM, Mehmet Erol Sanliturk wrote:
>
>
>
>
> On Mon, Oct 7, 2013 at 9:49 PM, Julian Elischer <julian at freebsd.org>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
>
>
>
>
>
>