* Bill Sommerfeld <sommerfeld at sun.com> [2006-05-03 19:32]:
> On Tue, 2006-05-02 at 18:05, Stephen Hahn wrote:
> > With various corrections and enhancements. More suggestions?
>
> one other thing to consider:
>
> if you too vigorously encourage the merging of /usr/gnu/bin/* features
> into /usr/bin you'll collide with the "advice" (section 6) of the
> opinion to 1999/645 CLIP:
The sentence
This policy is not a requirement for the /usr/gnu environment;
project teams may choose to enhance partially or completely the
/usr/bin variant as part of providing a /usr/gnu utility.
was trying to be neutral and not vigorous. We can adjust this, of
course.
> -------------
>
> 6. Advisory Information
>
> Retrofitting legacy utilities to the CLIP specification is a
> significant management decision. There are significant costs
> and marginal associated benefit. There would be nothing
> wrong with chartering projects to extend appropriately
> defined sets (as discussed in [1]) of utilities, but it is
> very likely that there are better ways to direct those
> resources. In particular, the committee sees little motiva-
> tion to extend the core UNIX utilities maintained by the ON
> Consolidation.
>
> The unchartered conversion of legacy utilities to the CLIP
> specification by engineers should also be discouraged. It
> is almost assured that a few such projects will be presented
> with the rationale that it was done on the engineer's own
> time. Accepting such projects is likely to lead to incon-
> sistent expectations on commands even though consistency is
> understood to be the primary desire of our customers. After
> a few such integrations, we can expect customer RFEs (possi-
> bly submitted as bugs) requesting that utilities in other
> areas of the system be converted.
>
> Despite the above concerns, implementing the common forms of
> the help and version options would be a universally desir-
> able activity.
>
> Functional areas are encouraged to develop (and publish)
> extended sets of preferred option letters and subcommand
> names.
>
> --------------
>
> now, this was written before opensolaris was on anyone's radar. Times
> have changed so maybe it's not as critical.. but engineer cycles are as
> always tight...
Is it just me, or did discouraging uneconomic CLIP extensions and
discouraging any extension get blended a bit in this section?
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com http://blogs.sun.com/sch/
