Joerg Schilling wrote:
> James Carlson <[EMAIL PROTECTED]> wrote:
>
>
>> I see no problem with making it easy to get "all" of the source and
>> making sure that people working on vi (for instance) can immediately
>> look at and enjoy the libc code, but that doesn't necessarily mean
>> that vi and libc need to be (or should be) managed as a single unit of
>> code.
>>
>
> This would be a modular approach.
>
> The problem with the current set of ON sources is that it is based on on
> modular thoughts but based on "burocracy" rules. This is e.g. causing the
> need to have "flag days".
We have some "natural" interface boundaries, e.g. the libc boundary, the
DDI (although there are very, very few DDI compliant drivers in
existence these days. Even my own afe and mxfe, which used to be DDI
compliant, ceased to be so when I updated them to use the GLDv3.)
Those natural boundaries are the logical places to make divisions, IMO.
E.g., software which relies exclusively on the public libc interfaces
could easily be moved to another consolidation. (I'm thinking stuff
like "vi", openssl, etc.)
> If we change things at all, I would first like to
> see the ON boundaries moved to have ON contain every source and include file
> that is needed to compile ON.
>
This is already the case, AFAIK. The exception here being the compiler
tools themselves. But all the other bits that you need to compile ON
are in ON. *HOWEVER*, it is also the case that some of those bits are
not open source. That is an orthogonal question to the consolidation
that the bits are delivered with. (And I agree we should be trying to
open those bits up, or find open source replacements.)
> Everything that does not fall under this category may later be a subject for
> discussion and become part of a split off.
>
I think we're having that discussion now.
-- Garrett
> Jörg
>
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
