Sorry, long day at work... Liane Praza wrote: > Rainer Heilke wrote: >> While I do not think the categories (nor my placement in them) are >> entirely accurate > > OK. My mistake.
No problem. As you said, this discussion is a lot to wade through. > , and also miss the grammatical argument, I do agree >> that the current proposal, as written, is of dubious value and may as >> well be closed. > > Then you're in support of Mark's proposed way forward? Yes, I think so. The current proposal, as written, does little for us, and some would argue is damaging. I think it should be withdrawn, and we all take a step back, discuss what we are wanting and why, and come to a consensus of how to accommodate the most people (and that includes the SMF team, which had specific reasons for the choices they made). The wiki may be a useful way to attain this goal without the waters getting muddied by 739 pages worth of discussion going every which way. > (I am. I'd like to see a way forward that involves the small set of > interested parties be able to report back to the larger aliases with an > updated proposal. The current conversation doesn't seem to be > converging on a concise updated proposal, so I'm not sure that > continuing it on this large alias is helpful. Agreed. The wiki also makes it easier for people like myself to keep abreast of the discussion when they do not always have access to their OpenSolaris.org email (which, for me as an example, goes to home). > There's a reasonably > small set of folks who are passionate about this as shown by continuing > to participate in the discussion, so it'd be good to see us discuss it > offline and either come up with a unified proposal, or at least a set of > clear competing proposals the larger group could then provide feedback on.) To be honest, I don't think all proposals need to be "competing." With the right willingness to give and take, we may be able to accommodate multiple parts. For example, thinking of my wish for a test function, perhaps calling it "start/stop" is not the best choice. Maybe we need an "enable -test" or something, which behaves the way I would like. That would satisfy those who do not want what could be a dangerous top-level verb. And so on. We will continue to need your input, though, in case something we all agree on inadvertently requires breaking something that is already in full production (like if "enable -test" requires significant replumbing of the "enable" function). Rainer -- Mind the gap.
