Roland Mainz wrote:
> Garrett D'Amore wrote:
>
>> Joseph Kowalski wrote:
>>
>>> Garrett D'Amore wrote:
>>>
> [snip]
>
>>> I've not heard from any other ARC members that they feel strongly
>>> about this. That doesn't mean they don't; we often just let the
>>> poster of the initial request continue to discuss.
>>>
>>> However, this is starting to sound like a lone voice here.
>>>
>>> Do other ARC members believe this is significant and we should
>>> continue discussing this?
>>>
>>> (I actually agree with Garrett's suggestion. However, Roland seemed to
>>> not accept this *suggestion*, so I think we should just drop it.)
>>>
>> That's fine. I offered to help as well if they wanted to follow my
>> suggestion.
>>
>> That said I don't want to suddenly have new functionality show up as
>> part of *this* case -- e.g. the HTTP functionality to which Roland was
>> alluding. If there were an attempt to grow that new functionality in
>> *this case*, then I'd derail.
>>
>
> Erm... why ? The /usr/lib/shell/ directory is _private_ - how we
> populate it (and "when") is AFAIK only a question for code review and
> not for the ARC case. Technically I have content for the directory but I
> wanted to wait until "shcomp" is available on the build machines (which
> needs usually five or more Nevada builds counting from our current
> putback to avoid the _pain_ for build machine admins caused by a "flag
> day").
>
Because *that* material is not related for this case. If you want to
have *another* case to add that material, you could probably do so
without contention.
I don't think its fair to say "project private" and leave various turds
throughout the filesystem. If *really* want a project private
directory, it would be better to select a truly project-specific name
like "/usr/lib/ksh93/" or
"/usr/lib/somecool-project-that-needs-lib-storage", and don't even take
the time to bring it to ARC. (Probably an item for CTeam review only at
that point, I think.)
In fact, if you are only providing private content, without any intent
to export functionality to other consumers, why do you want a common
directory for it? Why not just stick whatever files you need in either
/usr/lib or /usr/share (as appropriate)?
>
>> I will let the matter drop unless the submitter wants to follow my
>> suggestion (in which case my offer of help stands), or the submitter
>> takes the inadvisable action of trying to suddenly increase the scope of
>> this case by adding a bunch of new unrelated functionality into the
>> /usr/lib/shell directory.
>>
>
> The scope of the case includes /usr/lib/shell/ with _private_ content.
> The description of the hiearacial shell function library was only
> thought as a short description/justification why we want this directory.
>
Okay, it sounds like you don't want to run it as a separate case. I
can't say I'm thrilled by that, but neither am I upset enough to do
anything about it.
-- Garrett
