PSARC 2009/228 ls enhancements (draft opinion)

[James Carlson]

Roland Mainz writes:
> Erm... my concern is that "Commited" means "_very_ stable" and should be
> used very carefully. Changing "Commited" interfaces is AFAIK non-trivial
> and that's why I was suggesting to use "Uncommitted" for now until we
> have at least the "proof" that more than one implementation provides the
> same options with the same behaviour for at least two years.

Why should we care whether anyone else ever implements those options?
What if they remain GNU-only extensions until the end of time?

I think the point should be (a) telling users whether we intend to
make any incompatible changes and (b) if so, on what sort of release
boundary we would allow that sort of change to occur.  In this case,
it seems unlikely that there'd be some new development that would
cause us to make an incompatible change to (say) the --color option.
Even in the unlikely case that the GNU guys decided to break their own
'ls' implementation, we wouldn't reflexively follow suit.  At most, I
could imagine it being removed in the far future when nobody cares
anymore about VT320-style ttys, but even that'd be a normal EOF, which
we can do if the time comes.

You're certainly free to pursue whatever strategy you want within your
own project, so if you need to see multiple independent
implementations in order for ksh93 to commit to some new feature, then
do that.

However, as an architectural review matter for OpenSolaris, I don't
want to see new options forced to low stability levels merely because
they come from what some may see as "lesser" or "foreign" sources.
The author doesn't matter.  What does matter is accurately
representing future change, and making it possible for others to rely
on features that the system has.  Using artificially low stability
levels breaks that, and we've had a long and sorry history of
introducing actually stable things as "External" or "Volatile" merely
because the author or original inventor didn't carry the right
employment credentials.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677