Wyllys Ingersoll writes: > James Carlson wrote: > > What's the story behind this? The taxonomy says that previously > > "Evolving" things delivered via ON and reviewed by PSARC are > > ordinarily assumed to be "Committed." > > > > > > The original case for KMF (2005/074) had pktool(1) as Uncommitted . > I think this was overlooked when the man page was updated. The man page > diffs > included in this case are just changing that to be reflect the original > case.
OK; I see. > However, if this (and also kmfcfg(1)) should have been "Committed" in > the first place, > then I have no problem with making that change here. The question should be about what stability the users of the tool need, and what you're able to provide rather than a "should." My guess is that there are at least a few subcommands that would be likely to be used within scripts, meaning that users will need something that they can rely on. If that's something you can provide -- a promise that you're not going to break things in a later Minor release without prior notice -- then I think "Committed" would probably be better. -- 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
