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 > > > > > >Received on Tue Oct 08 2013 - 02:59:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:42 UTC