Mark Martin wrote:
> On Nov 19, 2007 7:39 AM, Rainer Heilke <rheilke at dragonhearth.com
> <mailto:rheilke at dragonhearth.com>> wrote:
>
>
>
> Ah. So, if the discussion concludes with this and my comments of last
> night, then he (and I) still isn't getting what he wanted.
>
> Rainer
>
>
> On that note, here's what I'm thinking. I don't really have the
> consensus I'm comfortable with. You, Darren, Jordan, Nicolas, and
> others have been making some good points recently regarding start/stop
> not adding enough as simply aliases for enable -t. IMHO, I agree.
>
> My current philosophy regarding this train is this:
>
> 1) I don't have the authority to just call the shot, and just
> implementing the RFE prima fascie because I won't get vetoed at the last
> minute serves no useful purpose and may lock in a useful verb which may
> be better suited having relatively different functionality.
> 2) There doesn't seem to be a lot of enthusiasm for simply implementing
> an alias. There seems to be some acceptance by the SMF team -- maybe
> because the proposal I initially made had little impact other than the
> aliases. I'd rather get more alignment from admins and SMF engineering.
> 3) Lots of ideas for other RFE's were championed which have similar
> touchpoints.
> 4) I opened the can of worms (with warning), and I would like to keep
> momentum going.
>
> So, I'm pretty sure I should be closing the bug off as wont-fix. I'll
> also put up a wiki to coalesce these things together ('-i',
> next-reboot-state vs current state, etc). I suspect the start -i -r -s
> -v -whatever that will win the most hearts and minds will probably
> require more than an alias and will require a ARC review and/or a vote
> -- or at least a decision process that I don't feel comfortable making
> on my own.
I think this sounds like a reasonable course of action. Here's why.
I believe the rough summary of the 3 main positions involved in this
discussion are:
1) "start/stop" is useful for novice admins and new users due to
familiarity with other systems. Either init.d or Windows (or
something else), and the goal is to be familiar, though not totally
abdicate the SMF model. This camp seems to be losing some steam
because of a combination of factors. Among those factors are
concern about guiding new admins towards temporary enables, and
the concerns from Rainer and Darren Reed that it neither helps
new users nor experienced admins. That's OK -- closing the bug now
doesn't preclude the ability to revisit later if new or more data
comes to light.
(Whether this is an 'alias' for existing enable technology or not
is irrelevant. The functionality must be described to users in
terms of behaviour, not in terms of an alias.)
2) There's a mode which is useful for advanced admin/developer use,
which might map to a "start" verb in terms of some similarities to
historical behaviour. Its value isn't in familiarity, but in its
actual functionality while actively developing and debugging a
service. The requirements of this are still in progress, but
this group is quite certain that existing SMF functionality
available through svcadm cannot be leveraged to meet their goal.
3) "start/stop" verbs for svcadm are good if they fill a useful purpose,
don't lead novice admins down a path that leads to errors, and
don't lead to confusion or grave misunderstandings about the
general SMF model. But, are equally happy to see it go away
if it can't do all that and satisfy the other positions. (Just to
clarify on the above assumption about the SMF team being in camp
#1, I actually hold position #3.)
If I've actually described the "advanced start/stop" (position #2) group
semi-accurately, it seems like your wiki page is the first step towards
defining this behaviour. Though, I hesitate to call it the familiar and
already overloaded "start/stop" verbs if it is meant for more advanced
users. I think that part of the discussion is very salient in future
progress, though names can be considered once there's clear agreement on
goals and behaviour.
If I *haven't* summarized any of the main positions well, how about the
people with concerns about the definition just mail Mark and I, and
we'll privately come to a one-paragraph agreement about the general
goals of the position you represent and re-post it to the aliases? (Or,
Mark's wiki.) I suspect lots of lurkers would like to see the
back-and-forth decrease some in favor of real progress.
I think your planned direction keeps pretty well with the realities of
the current situation as outlined above.
liane
