Re: HEADSUP: ibcs2 and svr4 compat headed for history

M. Warner Losh wrote:
> In message: <3949.1088292437_at_critter.freebsd.dk>
>             "Poul-Henning Kamp" <phk_at_phk.freebsd.dk> writes:
[ ... ]
>: Presumably you belive I did that to try to sneak this decision past
>: your highly sentitive nose, the bulk of the committers, our most
>: active users, the core team, the TRB, UN peace-keeping forces, and
>: Lloyds Register ?
> 
> Sarcasm doesn't help your case, and paints you as a 'cowboy'.

Indeed, this thread is so polarized it seems difficult to select a neutral 
message to reply to.  Data point: I don't use ibcs/srv4, and have no strong 
opinion or objection to the notion that they be removed.

>: (If you answer this correctly David, you win a little yellow rubber
>: mat you can stomp on next time you get upset about somebody not
>: "following procedures")
> 
> Actually, there are good reasons to follow those proceedures.  You'll
> get a lot less flack from people when you do.

My first reaction to this thread was "there's hope for Sun yet: this is why 
people pay for Solaris", and my preferences with regard to handling the 
removal of features are closely derived from the way Solaris handles the 
topic.  Requiring someone to document features going away before they get 
yanked and giving end-users a transition period long enough to see and respond 
to the notion that "XXX is going away" is important.

In other words, I care quite a bit about how "working, supported 
functionality" gets transitioned to "no longer available".  I'm not happy with 
the notion of "supported" -> "HEADS UP" -> one week -> gone.

Something like: "supported" -> "RFD about removal" -> agreement/decision
-> "HEADS UP" -> feature marked depreciated for one point release
-> time passes, while people either migrate their systems away from using
    whatever it is (or else complain that they still need the feature)
-> confirm removal decision -> gone.

What this means is that if some piece of functionality becomes a hinderance in 
terms of maintenance, there will be a period of a few months where people 
should refrain from breaking the depreciated stuff.  That doesn't seem like an 
impossible burden, given that if the existing code works, not changing the 
code at all until you've got something which works better is almost always 
possible and reasonable.

-- 
-Chuck