On Fri, May 1, 2009 06:07, James Carlson wrote: > Don Cragun writes: >> I see that now. As you have probably noticed, I'm getting the ARC mail >> in digest form. The digest that said this case had been approved didn't >> hit my inbox until after the PSARC meeting Wednesday. When I raised the > > I believe you were still on the line when we derailed and voted. That > was the actual approval -- derailing converts the fast-track to a full > case, and a vote causes it to close.
Hi Jim, Yes. I was saying that when the meeting started Wednesday, the case had already been marked closed approved in the case log, but the closure message had not yet made it to my inbox. You allowed a discussion on this case when I brought it up. During that discussion the case was reopened, derailed, and approved. > >> issue during the meeting, it seemed to me that I had raised the issue of >> optional option-arguments and didn't see any reaction to the issue >> before the case disappeared from the agenda. I was just asking for >> clarification on what had been decided. > > What was decided was that the CLIP infraction (regarding the > requirement for equivalent short options) was insignificant compared > to the GNU compatibility issue. The whole point of the project is to > allow users to specify "familiar" GNU options to 'ls', and have them > just work, rather than forcing people to reach for /usr/gnu/bin/ls, > which (sadly) doesn't support Solaris features. Yes, but I believe the CLIP case requires an explicit waiver from the ARC when CLIP guidelines are violated. The opinion for this case now modifies that CLIP requirement when long option optional option-arguments are the issue. > > Specifically, the vote was on allowing the case to go forward as > originally specified and without requiring a man page warning, as the > original specification did _not_ contain ambiguous constructs, because > the only optional option argument was a strict "--color[=WHEN]" > string, with no possibility of "--color WHEN". (In fact, I'd go so > far to say that to the extent that CLIP might call the former an > ambiguous construct, it's wrong. But that's a separate case.) > > If this case changes to include ambiguous constructs, then that'd be a > material change, and we'd have to revisit. I was just pointing out that the case included an ambiguous specification for how the optional option-arguments were to be presented. The case as presented in the email used '=' (not ambiguous), but the man page presented doesn't use '=' in the description of those options (ambiguous if the option-arguments are optional; unambiguous if the option-arguments are mandatory). That left me with the impression that the interface being ARCed was not clearly specified. From the e-mail discussion since then, it is now clear to me that the man page is wrong and the original case e-mail was mostly correct. From my experience with Sun's utilities tech writers, I have 95+% confidence that if the man page in the case directory is given to them as input the resulting man page will not correctly describe the intended interface. (Doug might get it right since he frequently reads ARC cases when he is updating man pages, but he doesn't usually work on utility man pages except as part of a project providing conformance to a new revision of the standards.) > >> is on the internal agenda. Furthermore, as I remember the internal >> agenda, there were links directly from the agenda to the case >> directories for all of the fast tracks. There are no links in the >> external agenda. I'm getting better at typing in the web addresses on >> the fly, but it is a lot slower than the direct links. > > I've agreed before that something needs to be done about this. I > still do. There's obviously more infrastructure work to be done. I > don't know of a schedule for it. Understood. Feel free to forward any part of this conversation if you think it might help get funding for this infrastructure work. Thanks, Don 408-978-8127 > > -- > 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 > >
