Garrett D'Amore wrote: > Roland Mainz wrote: > > Joseph Kowalski wrote: > >> Garrett D'Amore wrote: [snip] > > 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.)
... but this case is about updating a shell... why does the /usr/lib/shell/ stuff not "fit" into this case ? > 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. 1. Techinically the first consumer would be the "man-write" project - but that codebase is design to avoid triggering an ARC case. We just rip the code for "man" and "catman" out and replace it with something which is easier to maintain. But if we move the /usr/lib/shell/ stuff to that case then we trigger an ARC case and that was the thing we tried to avoid... 2. When JAVA started long ago they didn't had any consumers for their classes - why can't we start the same way for /usr/lib/shell/ and just provide some modules (based on some wishlists and the RFEs we have) and evolve them as part of the tree and not outside ? > 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. Uhm... lets continue the discussion on IRC, Ok (I'll be there at ~~1:00AM MET (after I found some food)) ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
