Maybe my concerns are better described this way.
The proposal is to remove a user control to a feature.
As this is the *only* user control to this feature, removal renders
the feature unusable, so therefore the case should not be about
removing the control, but removing the feature itself.
A justification for the removal was that it was only used on Sparc
platforms that are no longer available. This will bring up the
question: "should the feature have been available on other hardware
platforms (or, is it really a bug that it wasn't on x86)?" Make
sure there is an answer.
It has been hinted that there may be new requirements for similar or
improved features. Don't be hinting, be specific. If it is known
that there will be a need for the feature, then the case should be
describing the intent to use the similar or improved feature,
and let this justify the removal of the old cruft
There was a suggestion that the current feature is poor at best
(possibly outright broken). This potentially suggests that there
should first be a case to describe how the feature *should* be
controlled before the case to deprecate the old controls.
I am not advocating that what is there is sufficient (especially since
I believe that it is not) or that it we even want this feature, but
that the case be complete. If the feature is desired, then we should
be describing how we want it used. If it is not desired, we should be
describing why it should go away. Effectively stating that a control
should go away because it wasn't designed properly in the first place
will not go over well.
Cheers!
---- Randy
_______________________________________________
pm-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pm-discuss
