Roland Mainz wrote:
> Alan Coopersmith wrote:
>
>> I'm sponsoring this fast-track request on behalf of the
>> ksh93-integration and busybox projects. The timeout is
>> set for Friday, July 31, 2009.
>>
> [snip]
>
> Just to clarify (since both points have IMHO been either ignored or
> misinterpreted several times):
> 1. We do _not_ intent to remove or discontinue normal documentation,
> including manual pages (in fact I've been a long-term advocate of
> getting Solaris moved to DocBook/XML-based manual pages (including
> _shipping_ them as part of the installation instead of the nroff
> versions (that's why I even worked on a /usr/bin/man replacement
> codebase))).
>
I heard you. However, the upstream sources have *not* agreed with this
approach.
> 2. The whole idea of "--man" was to re-use the existing information used
> by the |libast::getopts()| call to provide quick access to _never_
> information. It was _never_ intended (by this project (but not upstream
> (for which the --nroff/--man output is _sufficient_))) to be a
> _complete_ manual page with all manpage sections required by Solaris.
> From an ARC point of view I only see this (and intent to treat it) as an
> extended form of the "--help" option which AFAIK has significant amount
> of precendet. I really wish ARC would simply see "--man" as such, too.
>
The problem is that this distinction is lost to *users*. You're calling
it --man, and you're presenting it as a manual page. Saying its one
thing, then presenting it as something else doesn't make sense.
> What I still try to offer is the "truce" of letting us work in _peace_
> on the idea of having one master DocBook/XML manual page file from which
> both the normal manpages and the getopts strings are generated from
> (manpages have the full information, the getopts stuff just the terse
> information to keep it small).
>
> Garret, would you accept the "truce" and remove the "de-rail", please ?
>
No, its too late for that. The project has been derailed for a vote.
As I said, you don't have do anything else at this point except wait for
the vote on Wednesday (unless you'd prefer us to reschedule for another
date).
Actually lets make this more explicit. Would you like us to take a vote
on Wednesday, or would you like to defer this to another meeting? Its
your project, so we can do the vote at any regular PSARC meeting that
you feel is appropriate. I'd recommend trying to be present at the
meeting, however.
- Garrett
> ----
>
> Bye,
> Roland
>
>
