Re: Forking on Github and feedback

[Gregory Casamento]

Maxthon,

You never even requested a copyright assignment form! :)  I'm not sure
what you mean by "my changes are rejected yet again."   If you had
submitted some changes they would have been considered.

GC

On Fri, Dec 4, 2015 at 11:43 AM, 陈北宗 <address@hidden> wrote:
> Also a little notification, I am bumping soname of libobjc2 in my fork
> (“libobjc2-ng” version 2.0) to libobjc.so.6. Debian occupied libobjc.so.4
> and libobjc.so.5 so I performed this preventive sonamp bump. Also since this
> refactor affected almost all parts of Base and CoreBase all soname versions
> and major versions will be bumped.
>
> On Dec 4, 2015, at 22:24, Ivan Vučica <address@hidden> wrote:
>
> 1) and 2) will probably not happen for core project due to desire to build
> on odd platforms.
> 3) was proposed, I don't think anyone objected.
> 4) Dependency on libdispatch? *grumble*
> No comments on the remainder. Even these items seem not completely necessary
> or compelling, and counter to the desire to run on many platforms.
>
> Regarding distant goals:
> 14) Does this mean you intend to support XC's spec file format and plugin
> system?
> 15) Opal, being a 2d painting engine, has no relation to the compositing
> system (Wayland) nor a 3d rendering/compositing system (EGL). Please don't
> do this without expanding this.
> 17) I approve of this: not as a 'clone', but as a 'user-friendly,
> comparable, compatible alternative'. I started work on Zcode a while ago,
> but since I want to have a nice build system based on XC3-{like,compatible}
> plugins and spec-files, it got stuck. In fact, it makes sense to work on the
> build system first, for which the Xcode3-and-before-era Xcode is just a
> frontend with an integrated editor. How interesting will your implementation
> of build graph nodes classes be?
>
> I also noticed you mention Opal in relation to CF a few times. Why?
>
> On Fri, Dec 4, 2015 at 1:04 PM 陈北宗 <address@hidden> wrote:
>>
>> Dear List:
>>
>> I just forked libobjc2, base and corebase so I can restart the refactor
>> project again, now using OS X 10.11 as the refactoring standard. I would
>> like to know how should I contribute back?
>>
>> Project plan:
>>
>> 1) Building with clang 3.6+ mandatory, even for C-only projects. This is
>> to allow...
>> 2) … gnustep-make as well as use of autotools or cmake deprecated,
>> replaced with __have_include() macro provided by clang. Also parallelisation
>> that used to plague gnustep-make should work better now. For other projects,
>> Xcode project files would be used instead.
>> 3) GC in libobjc2 removed and ARC mandated, just like OS X 10.11 and iOS
>> 5.
>> 4) The base build order will be libobjc2 - libdispatch -
>> gnustep-base-headers - gnustep-corebase - gnustep-base. The tangled look is
>> from the fact that a few Base classes are moved to CoreBase for the sake of
>> TFB.
>> 5) libobjc2 will install blocks-related headers at correct locations as if
>> installed from libBlocksRuntime, as well as creating a symlink for
>> libBlocksRuntime, essentially replacing it entirely.
>> 6) libobjc-opts removed - LLVM 3.4 and beyond not supported anyway, and
>> LLVM 3.6+ mandated here.
>> 7) NSZone, CFAllocator and part of NSObject moved to libobjc2 (allow TFB
>> to be implemented in CoreBase)
>> 8) Added TFB pairs for the sake of simplicity (should not break contract
>> if used properly): NSZone vs CFAllocator, NSRunLoop vs CFRunLoop,
>> NSCountedSet vs CFBag, NSIndexSet vs CFBitVector, and a few more.
>> 9) I will figure out a way to put CFNetwork in, maybe as a separate
>> library, and reimplement a few Base classes on top of that.
>> 10) CommonCrypto API is used as an abstract layer above OpenSSL and
>> GnuTLS, replacing the crypto bundle. It is built separately as
>> libcommoncrypto-openssl and libcommoncrypto-gnutls dynamic libraries but
>> only one can be linked at a time. Both libraries will be under a 3-clause
>> BSD license, acting as a legal buffer between either OpenSSL license mix or
>> LGPL from the crypto library, and LGPL or GPL of the framework proper.
>> 11) dispatch-io will be used heavily across CF and Foundation -
>> libdispatch now a hard dependency.
>> 12) I will try to find some mach port analogue from within POSIX API. DO
>> and XPC will depend on it.
>> 13) A set of macros for creating new CF classes will be provided (for the
>> sake of Opal)
>>
>> Distant goals:
>>
>> 14) DVTFoundation and xcodebuild cloned.
>> 15) Opal, written on top of Wayland and EGL, replaces gnustep-back.
>> 16) GUI would be taking advantage of ARC and Opal.
>> 17) StepCode, a Xcode clone, based on libclang.
>>
>> Max.
>> _______________________________________________
>> Gnustep-dev mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>



-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/