>> Is there an issue with having these individual cases coming
>> one-by-one?
>
> Yes, because it's just too much work and email to do it one by one.
>
> Is there a rule that an ARC case needs to delivered as one deliverable?
>
> If not, then put them in one case and make "staged delivery" part of
> the case.
That was and still is the original intention. However, it was my
belief that the incremental progress offered by the individual cases
made sense until the larger, clean-up-the-rest proposal was ready.
> One important issue here is that the more cases like this we see, the less
> diligent we might become and then suddenly we WILL have /usr/libexec which,
> I think, we clearly do not want.
Perhaps although I think one could also argue the fact that it was
/usr/libexec showing up in the much smaller GNU tar case which caused
folks to take notice.
Speaking to the larger picture, /usr/sfw came into existence via
PSARC 2000/487 Solaris/Linux API compatibility
Over time, we've become wiser :-) and realized that hiding those
components was well-intentioned, but a mistake and so the the intent of
these individual cases and the larger one is simply to align the
contents of /usr/sfw to the decisions made in
PSARC 2005/185 Enabling serendipitous discovery
PSARC 2007/047 /usr/gnu
The overall intent is to eventually leave /usr/sfw as a directory with
symbolic links for backwards compatibility of commands and perhaps some
selected other components.
So how would PSARC like to proceed? Can the currently filed cases
continue on their already filed routes while we hold off on filing any
new such cases? There are a couple of other fast-tracks not yet filed
but getting close to being ready including one for "gcc" and
"binutils". Should we continue with those as well but leave any others
for the larger case?
dsc
