HEADSUP: ibcs2 and svr4 compat headed for history
cswiger at mac.com
Sun Jun 27 12:55:09 PDT 2004
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.
More information about the freebsd-current