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"). > 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. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
