ls(1) new command line options '-/' and '-%': CIFS system attributes support [PSARC/2007/394 FastTrack timeout 07/11/2007]

[Joseph Kowalski]

I think this discussion, although worthwhile, is starting to be 
out-of-bounds
for this exact PSARC case.  Additional discussion should be in another
forum.

Still, one big clarification should be made....

Joerg Schilling wrote:
> If the policy does no longer meet the reality, it needs to be updated.
> I am willing to cooperate for such an updated guideline.
>   
> BTW: could you explain what you understand by "incremental additions are not 
> going to accepted"?
>   
First, I said this as an absolute.  That isn't right.  This "assertion" 
is just my
view as to what SAC would accept.

What I was trying to say is that I don't think that a simple addition 
isn't going
to provide much value to the specification.  For example, what if somebody
proposed that in "gnu like" fashion, optional argument values were to be
supported.  Its an ambiguous construction (that gnu seem OK with - go 
figure),
but it could be proposed.  This is the type of "incremental addition" that I
doubt will be accepted.

Why?  Because we've already had the discussion when CLIP was accepted.
All the simple "incremental additions" were all ready considered.  The 
requirement
that long-options have equivalent short-options was beaten to death when
CLIP was considered.  Been there,... Done that,...

I wasn't joking that this took something on the order of 4 years and 
"killed" a
number of sponsors.  I'm the sponsor who finally got the discussion to 
close.
Nobody got the specific prose they wanted.  I certainly didn't get the prose
I wanted.  I'm actually proud that I was able to close this - not that 
its a great
specification, but that I was able to negotiate so many diverse opinions.

What you don't like (long-options require short-option equivalent) has 
already
been beaten to death.  There is nothing a single person, or even a small 
group, can
change something like this because of the **huge** group of people which
weighed-in on this policy.  It has a **lot** of inertia behind it.

So, how can such a change happen?

One way is that a new "CLIP" started from scratch.  If might not be based
of the existing CLIP (which was based on the 1991 getopt case).  For all
I know, options will be preceded by "/" rather than "-".   8^)  This is the
"non-incremental" type of change I was referring to.

The other way would be that a huge population of community members
believe that such an incremental change is a "good thing".  This could
happen, and maybe happen in a few years, but I doubt that such a "huge
population" of community members will have such a uniform belief any
time soon.  (Hurt me with that problem.)

Now, coming down from the 50,000 ft level, you said "If the policy does
no longer meet the reality".  Have bunches of new utilities with large 
numbers
of options just suddenly appeared? I don't think so.  When we considered
CLIP, we knew that some utilities had this property.  We knew they couldn't
conform to CLIP (in this one way).  So what?  There are exceptions.  The
goal is to limit the number of exceptions, particularly extraneous 
exceptions.

(Let's not decompose is the current examples are extraneous or not.)

- jek3