Frankly, the effort to create a new case (fast track or otherwise) is so
small, that I'd just spin off the /usr/lib/shell part into a separate
fast track. If you would like a sponsor for it, write up a quick draft
-- you can probably just extract the relevant text from this case -- and
I'll be happy to sponsor it for you. (Really, I'm not trying to make
more work for you, but simply make it easier to review/discuss, and
decrease overall contention.)
As far as populating /usr/lib/shell with other unrelated functionality
goes: if you have functionality to populate there that is not related to
the ksh93 update portions of this case, then I *strongly* request you
submit that as a separate case. I feel strongly enough about that, that
I'll probably hit the derail button if you try to squeeze that into this
case.
Please also note, I'm merely requesting a separation of review
components. You can deliver the bits together, or separately, according
to whatever arrangements you and the CTeam make.
-- Garrett
Roland Mainz wrote:
> Garrett D'Amore wrote:
>
>> Roland Mainz wrote:
>>
>>> AFAIK you mean /usr/lib/shell/ and the answer is "maybe", depending on
>>> time. The first real consumer may be the "man-rewrite" project which
>>> stuffs the shared shell code into
>>> usr/lib/shell/ksh/org/opensolaris/man/misc/ or something like that (e.g.
>>> common shell functions for DocBook/SGML+SolBook/SGML+DOcBook/XML manpage
>>> handling and the catman crawler dispatcher code)
>>>
>>>
>> That would not be this case, though, right? So you aren't populating
>> anything there as part of what you need for the other portions of this
>> case, right?
>>
>
> No, I didn't indent to do it for the upcoming putback since "shcomp" is
> first introduced by the same putback - which means we can't compile the
> script modules and have to deliver them as readable script code. The
> original idea was to provide only compiled script modules and an
> interface description so noone can just look at the code and rely on
> implementation details not described in the interface specification...
> ... on the other side I can populate /usr/lib/shell/ easily with the
> common code for HTTP handing, the function set to manage child processes
> in a fine-grained manner, application locks (remeber the example code I
> posted a while ago for file-based mutexes) and some other stuff and
> offer this API for ARC contracts...
>
>
>>>> If not, you might consider running that as a separate fast track.
>>>>
>>> Why ? The directory is explcitly marked as "project private" for now.
>>> AFAIK we don't have to notify ARC about further activities there until
>>> we start making ARC contracts or open the interfaces there...
>>>
>> Because it isn't intrinsic to this case, and proposes things that have
>> impact outside of ksh93 (you've suggested bash, zsh, etc.) I'd rather
>> see that as a separate case. (It doesn't necessarily mean that such a
>> case will be contentious.)
>>
>
> Well, we could rename the ARC case to be a joint ARC case of the
> "ksh93-integration" (which covers ksh93) and "shell" project (which
> covers bash, zsh, POSIX shell, tcsh, csh, dash etc.) ... would that work
> ?
>
> ----
>
> Bye,
> Roland
>
>
