Garrett D'Amore wrote: > Roland Mainz wrote: > > Garrett D'Amore wrote: > >> I've posted a draft opinion "filename opinion-draft.txt" (and also .ms) > >> in the case directory for review. Its attached to this message as > >> well. Thanks. > >> > > [snip] > > > >> 3. Interfaces > >> > >> The project exports the following interfaces. > >> > >> _______________________________________________ > >> | Interfaces Exported | > >> |_________________|________________|__________| > >> |Interface | Classification| Comments| > >> |_________________|________________|__________| > >> |/usr/bin/ls | Committed | | > >> |/usr/xpg4/bin/ls | Committed | | > >> |/usr/xpg6/bin/ls | Committed | | > >> |_________________|________________|__________| > > > > > > I have a small request: > > For the commands replaced by the AT&T AST commands (currently done via > > the ksh93-integration project) we _carefully_ investigated which > > options+features (including long options) are available by which > > implementation (e.g. we investigated Solaris/SystemV, GNU, BSD and AST > > implementations). > > Technically we only made options "Commited" (or added them to the AST > > codebase) which are implemented identically by two or more > > implementations and must exist for >= two years and set-up the rule that > > options+features which are only available in one implementation or exist > > since less than two years must be "Uncommited" (to avoid that the > > implementation somehow changes and therefore breaks a "Commited" > > interface). > > > > IMO it may be nice to 1) apply the same set of rules to /usr/bin/ls, > > /usr/xpg4/bin/ls and /usr/bin/xpg6/bin/ls and 2) make options which are > > somehow "disputed" in this case either "Uncommited" or "Volatile" (I can > > help with that on demand since we already know the drill from > > ksh93-integration update1+update2+ammendents+etc.). > > IMO, there is little value in a familiarity case where the options are > not themselves relatively stable.
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. > Anyway, the case was approved with Committed. Unless the project team > wants to ask ARC to demote them, they stand as is at Committed. Ok... ;-/ ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
