Hi Olga,
Please find my comments in-line below...
Cheers,
Don
On Feb 28, 2010, at 7:43 PM, ????? ???????????? wrote:
> Please review the "POSIX utility community Group Proposal" below until
> Tuesday 18:00h MEST and send feedback to
> <shell-discuss at opensolaris.org>.
> I will send out the revised proposal Tuesday 19.00h MEST.
>
> Olga
>
> =========================================
> POSIX utility community Group Proposal
>
> Summary
>
> -----------------------------------------------------------------
>
> The following is a proposal for the creation of an OpenSolaris POSIX
> utility community group that focuses on long-term innovation,
> enhancement, development, testing and maintainance of the basic
s/maintainance/maintenance/
> POSIX commands and utilities in Solaris.
s/commands and //
(In the terminology used by the standard, commands are invocations of
utilities. Therefore, the utility community only needs to maintain
utilities.)
>
>
> Background
>
> -----------------------------------------------------------------
>
> Right now, the OpenSolaris userland environment, specifically the
> POSIX-mandated commands and utilities, lacks a dedicated community which
s/commands and //
> can guide its progressive evolution. This has a few unfortunate side
> effects: there is no *consistent* and modern API, there's no attention
> paid to how user-friendly the utilities are (it's been lamented that
> Solaris's userland is actively *hostile* to converts), there's been no
> real innovation in the Solaris userland for many years (except
> unconditionally using GNU coreutils as replacement instead of
> creating own *innovations* and focusing on the traditional strength of
> Solaris such as API stability, good internationalisation, performance,
> good testing, etc.), and there are no feedback loops or *joint*
> development with other vendors.
>
> As a result, this lack of manpower in the form of a dedicated
> community has resulted in a splintering of userland maintenance,
> alienating customers who rely on traditional Solaris features (like
> API stability, internationalisation, performance, ...) and general
> frustration with the userland (for example, stealing from GNU
> coreutils and putting their utilities in the front of the $PATH
> and relegating "standard" tools to demeaning locations such as
> /usr/has/bin).
>
> Thus far, without manpower and a community, no one is taking the
> responsibility to innovate and improve the utilities, following a
> strategic plan for the environment as a whole rather than a
> piecemeal approach for whatever utility is "broken today."
>
>
> Focus and Goals
> -----------------------------------------------------------------
>
> The POSIX commands community's goal is to own, enhance, develop
s/commands/utility
(To make the community name consistent in this proposal...)
> and maintain the POSIX commands in (Open-)Solaris. We discuss
s/commands/utilities/
> POSIX commands-specific topics here. Users can ask questions and
s/commands/utility/
> report problems about the POSIX commands of (Open-)Solaris. The
s/commands/utilities/
> community work together to answer the questions, fix bugs,
> implement enhancements and work with the Austin Group to add new
> features to the next version of the POSIX standard.
s/version/revision/
>
> There are several projects&topics in the plan:
> - Implement bug fixes
> - Implement common BSD and GNU features based on the AT&T AST
> code base (the basis for this already exists with the
> ksh93-integration project) assuming they do not conflict
> with the POSIX standard (we will *not* break the POSIX
> standard in *any* case)
> Standard mode of operation is to implement missing features
> one-by-one if they are requested (or useful) and the ARC
> stability is set to "uncommitted" unless more than two
> implementations out of { AST, *BSD, GNU, MacOSX } implement
> them - in that case promotion to "committed" should be done and
> a proposal for inclusion into the next POSIX standard be made.
s/next/next revision of the/
> - Invite other operating systems and vendors to partake
> in the projects and community (i.e. AT&T (AST), Apple
> (busybox) etc.)
(Although accetance migh not be likely, HP and IBM should also be
invited.)
> - Implement own test suite, preferably one test suite module
s/own/our own/???
> per bug id
> - Improve performance
> - Improve portability of the code base
> - Improve maintainability of the code base
> - Improve observability (e.g. Dtrace)
> - Make the code base 64bit clean
> - Strengthen the POSIX conformance
s/the //
> - Strengthen the i18n (multibyte) support
s/the //
> - <...insert more goals...>
>
> Initial projects include:
> - ksh93-integration project
> - shell project
> - busybox (POSIX core) development project
> - shxml (XML shell API) development project
> - POSIX utility modernisation
>
> The community will own the following commands and have the sole
s/commands/utilities/
> responsibility to change them (note that many of these commands are
> actually shell special builtins and are only exposed in the fileystem
s/special/regular/
(The special built-ins in the standard are break, colon (:), continue,
dot (.), eval, exec, exit, export, readonly, return, set, shift, times,
trap, and unset.)
> for standard conformance reasons):
I'm evaluating the following list based on the 2008 revision of the
standard. Since you later mention /usr/xpg4/bin, we need to also
check for utilities marked obsolescent and dropped in the last two
prior revisions. I don't have time to do that research tonight.
admin is in the development option in the standard
> /usr/bin/alias
ar and asa are in the standard
> /usr/bin/at
> /usr/bin/awk
> /usr/bin/basename
> /usr/bin/batch
> /usr/bin/bc
> /usr/bin/bg
c99 is in the development option in the standard
cal in the standard
> /usr/bin/cat
> /usr/bin/cd
cflow is in the development option in the standard
> /usr/bin/chgrp
> /usr/bin/chmod
> /usr/bin/chown
cksum is in the standard
> /usr/bin/cmp
> /usr/bin/comm
> /usr/bin/command
compress is in the X/Open system interfaces option in the standard
> /usr/bin/cp
> /usr/bin/crontab
csplit is in the standard
> /usr/bin/ctags
> /usr/bin/cut
cxref is in the development option in the standard
> /usr/bin/date
> /usr/bin/dc
dc is not in the standard
dd and delta are in the standard
> /usr/bin/df
diff is in the standard
> /usr/bin/dirname
> /usr/bin/du
echo is in the standard
> /usr/bin/ed
> /usr/bin/edit
edit is not in the standard
> /usr/bin/egrep
egrep is no longer in the standard
> /usr/bin/env
> /usr/bin/ex
expand is in the standard
> /usr/bin/expr
false is in the standard
> /usr/bin/fc
> /usr/bin/fg
> /usr/bin/fgrep
fgrep is no longer in the standard
> /usr/bin/file
> /usr/bin/find
> /usr/bin/fmt
> /usr/bin/fold
fort77 is in the FORTRAN option in the standard
fuser and gencat are in the standard
get is in the development option in the standard
> /usr/bin/getconf
> /usr/bin/getopts
> /usr/bin/grep
> /usr/bin/hash
> /usr/bin/head
iconv is in the standard
> /usr/bin/id
ipcrm is in the standard
> /usr/bin/ipcs
> /usr/bin/jobs
> /usr/bin/join
> /usr/bin/kill
lex is in the development option in the standard
link is in the X/Open system interfaces option in the standard
> /usr/bin/ln
locale, localedef, and logger are in the standard
> /usr/bin/logname
lp is in the standard
> /usr/bin/ls
m4 and mailx are in the standard
make is in the development option in the standard
man and mesg are in the standard
> /usr/bin/mkdir
> /usr/bin/mkfifo
> /usr/bin/more
> /usr/bin/mv
newgrp is in the standard
> /usr/bin/nice
> /usr/bin/nl
nm is in the development option in the standard
> /usr/bin/nohup
> /usr/bin/od
> /usr/bin/paste
patch is in the standard
> /usr/bin/pathchk
> /usr/bin/pax
> /usr/bin/pr
> /usr/bin/printf
prs is in the developemnt option in the standard
ps and pwd are in the standard
qalter, qdel, qhold, qmove, qmsg, qrerun, qrls, qselect, qsig, qstat,
and qsub are in the obsolescent batch utilities option in the standard.
The batch utilities option is not supported in Solaris 10.
> /usr/bin/read
renice is in the standard
> /usr/bin/rev
rev is not in the standard
> /usr/bin/rm
rmdel is in the development option in the standard
> /usr/bin/rmdir
sact and sccs are in the development option in the standard
> /usr/bin/sed
> /usr/bin/sh
sh is in the standard (but on Solaris systems it resides in
/usr/xpg?/bin; not /usr/bin).
sleep is in the standard
> /usr/bin/sort
split, strings, and strip are in the standard
> /usr/bin/stty
> /usr/bin/sum
sum is no longer in the standard
> /usr/bin/sync
sync is not in the standard (never in POSIX; may have been in an
earlier version of XPG)
tabs is in the X/Open system interfaces option in the standard
> /usr/bin/tail
talk is in the user portability option in the standard
> /usr/bin/tee
> /usr/bin/test
[ expression ]
is also in the standard as a synonym for
test expression
time, touch, and tput are in the standard
> /usr/bin/tr
true and tsort are in the standard
> /usr/bin/tty
> /usr/bin/type
> /usr/bin/ulimit
> /usr/bin/umask
> /usr/bin/unalias
> /usr/bin/uname
uncompress is in the X/Open system interfaces option in the standard
unexpand is in the standard
unexpand is in the development option in the standard
> /usr/bin/uniq
unlink is in the X/Open system interfaces option in the standard
uucp is in the UUCP utilities option in the standard
uudecode and uuencode are in the standard
uustat and uux are in the UUCP utilities option in the standard
val is in the developemnt option in the standard
> /usr/bin/vedit
vedit is not in the standard
> /usr/bin/vi
> /usr/bin/view
view is not in the standard
> /usr/bin/wait
> /usr/bin/wc
what is in the development option in the standard
> /usr/bin/who
write is in the standard
> /usr/bin/xargs
yacc is in the development option in the standard
> /usr/xpg4/bin/*
> /usr/xpg6/bin/*
> <CHECK if these are a) all commands covered by POSIX and whether
> b) all commands listed here are defined by POSIX>
See notes above...
>
> The community will *NOT* handle any commands outside this scope
> (i.e. the scope of this community is *STRICTLY* defined by
> the POSIX standard).
You need to also take responsibility for utilities that are linked
to standard utilities (e.g., grep is a standard utility with links
to egrep and fgrep; ex and vi are in the standard with a link to
view [and a few other things if I remember correctly]).
You will need a strong connection with the compiler group if you
are going to take over development and maintenance of the utilities
in the development option in the standard.
>
>
> Leadership
>
> -----------------------------------------------------------------
>
> There will be core contributors and leaders to make decisions
> related to POSIX commands community, including creating new
> projects, maintaining existing projects.
>
> Core Contributors who are nominating the community
>
> * Don Cragun
> * April Chin
> * Roland Mainz
> * Olga Kryzhanovska
It would have been polite to ask me whether I support the creation
of this new community before announcing to the world that I have done
so. Has April said that she supports this action? If the above list
is intended to be the list of leaders for this new community, what
responsibilities would this entail for me?
>
> Initial core contributors will be:
>
> * April Chin
> * Roland Mainz
> * Matt Lewandowsky
> * David Korn
> * Glenn Fowler
> * Don Cragun
> * Irek Szczesniak
> * Knut Reinert
> * Olga Kryzhanovska
> * Jennifer Pioch
> * Wendy Phillips
> * Norm Jacobs
> * Basabi Bhattacharya
> * Craig Mohrman
> * Kenjiro Tsuji
> * Carol Fields
> * Robbin Kawabata
> * Kristin Amundsen
> * Mike Light
> <check whether Nico, James, Ralf and Moinak have any
> interest>
Have you verified that the people in the above list (other than me)
that were laid off by Sun over a year ago from the standards
conformance, libraries, and utilities group (April, Wendy, Basabi,
Craig, Kenjiro, Carol, Robbin, Kristin, and Mike) would accept core
contributor responsibilities?
>
> --
> , _ _ ,
> { \/`o;====- Olga Kryzhanovska -====;o`\/ }
> .----'-/`-/ olga.kryzhanovska at gmail.com \-`\-'----.
> `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'`
> /\/\ /\/\
> `--` `--`
> _______________________________________________
> ogb-discuss mailing list
> ogb-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
>
