Policy for removing working code

[perryh at pluto.rain.com]

John Baldwin <jhb at freebsd.org> wrote:

> We can't e-mail announce@ every time something is going to
> be removed.  That would be way too much spam for that list.

That may depend on how often something substantial is removed :)

> I do think stable@ is a good place to e-mail ...

Good, perhaps even "necessary", but is it "sufficient"?  Those
following a -STABLE branch are expected to read stable@, but
what about those who are following a security branch?

> I do think that the general rule is that stable@ should be on
> the list.  It is true that that did not happen in this case (and
> probably should have), but it does happen in the typical case.
> I would chalk this up to a one-time slip-up, not a systemic problem.

In light of this slip-up having now resulted in at least one user
having the rug yanked out from under him, perhaps the security
officer should be approached WRT continuing support for 6.4 until
ISDN is resurrected (which, to judge from other postings in this
thread, seems unlikely to amount to "indefinitely").

> ... we lost a few SCSI HBA drivers during the transition to CAM
> (e.g. wds(4) was not present in 4.x but was eventually CAM-ified
> and reappeared in 5.0).  I suspect there was far less notice given
> for those drivers than for ISDN (multiple notices to arch@ and
> current@ spread out across many months).

But, as noted previously, not to any list that someone following a
security branch would be expected to read.  Beyond that, I suspect
that dropping an HBA or three would have been far less burdensome
on users of the hardware in question than dropping ISDN is on its
users.  One can always replace a no-longer-supported HBA with a
supported one, or (worst case) replace the whole box.  In contrast,
someone located beyond DSL range may have no other viable option
than ISDN.

Perhaps it would be advisable to e-mail announce@ when something
is to be removed _and_ there is no recommended migration path.
That should reduce the frequency of such postings considerably
compared with the strawman suggestion that

> ... every time something is going to be removed

would overload the list.