Roland Mainz wrote:
> Joseph Kowalski wrote:
>
>> Garrett D'Amore wrote:
>>
>>> 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.
>>>
> [snip]
>
>> (I actually agree with Garrett's suggestion. However, Roland seemed to
>> not accept this *suggestion*, so I think we should just drop it.)
>>
>
> Erm... I'm just answering the ARC emails out of sync and I'm simply not
> fast enought to answer all emails ASAP (around seven emails are already
> in the drafts folder but I'm a slow email writer and usually need lots
> of time...) ...
> ... we can move the /usr/lib/shell/ stuff out into a seperate ARC case
> to make it simpler but the content would be the same - we add
> /usr/lib/shell/, it's private and we run an experiment there which is
> private until we open it for the public... and then my question is: Why
> should we make a seperate ARC case if the content of the case is the
> same ?
>
The reason is to allow the cases to be reviewed, and approved separately.
If there were some kind of technical linkage or dependency, then sure,
keeping them together might make sense. But IIUC that's not case.
(Put another way, why not have the EOF of SoundBlaster Pro support also
bundled in this case? Answer: Because there is little or no overlap or
relation.)
I'm also of the believe that the /usr/lib/shell case really should
probably wait until you have a consumer for it. Putting out a project
private directory with nothing in it really doesn't serve us much good, IMO.
Anyway, if you want to separate it out, send me a document with those
bits pruned out, and I'll go ahead and submit them whenever you're ready
for me to.
-- Garrett
