Policy for removing working code

[Vadim Goncharov]

Hi John Baldwin! 

On Wed, 8 Sep 2010 10:21:47 -0400; John Baldwin wrote about 'Re: Policy for removing working code':

>>> No, that would require maintaining two network stacks, not just one.  The
>>> shims to allow unlocked code to run were not trivial.  The choices were this:
>> 
>>> 1) Moving forward on work to allow the network stack to scale on SMP
>>>    systems (e.g. modern x86 multi-core servers) and support higher rate
>>>    protocols such as 10GB, 40GB, and 100GB.
>> 
>>> 2) Stop all progress on making the network stack scale on SMP.
>> 
>>> I'm sorry, but 2) just isn't feasible.  Not if FreeBSD is to continue to be a
>>> modern, relevant system.
>> 
>> If it is the only variants, then I'll agree (but only on this part). Are there
>> really no other variants? What do other OSes to which, as was said, we have to
>> compete? E.g. Linux?
>
> Yes, other OS's (Windows, Linux, Solaris) all are working on the multi-core
> problem.  OS's that aren't working on this will soon be obsolete.  Even modern
> embedded systems are multi-core (e.g. many MIPs chips now include multiple
> cores on a chip, even SMT similar to Intel's HyperThreading on RMI's MIPs
> SOCs).

My question is not quite the same as that to which you've answered. I agree
that non-SMP OS's will be obsolete, but what that OSes do in such particular
cases?

>>> Also, despite your claims to the contrary, there _was_ adequate notice:
>>>    http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html
>>> This was also documented in the release notes for 7.0:
>>>    http://www.freebsd.org/releases/7.0R/relnotes.html
>> 
>> No, my claims were that there was no _adequate_ notice, and this links
>> acknowledge this. 7.0 Release notes state about broken ISDN as an already
>> happened fact, user can't do anything about it already. As I've shown in
>> message to vwe@, it wasn't in announce@ and even in stable at . Number of
>> users/subscribers of lists can be expressed as:
>> 
>> # devel lists < # current@ < # stable@ < # announce@ < # of total FreeBSD users
>> 
>> While we can't do anything with those who not subscribed even to announce@
>> (though should it be duplicated on www may be?), number of announce@ readers
>> is still MUCH more than that of current@, not even mention devel lists.

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

No, not everytime and everything, of course. That will go to far to other end.
I mean every major event, e.g. each ordinary driver is not worth noting (too
much spam), but in this case there were TWO not drivers, but subsystems (ISDN
and netatm). One symptom that could indicate this is major event, not minor, is
call for volunteers. This is definitely happens not too often.

> I do think stable@ is a good place
> to e-mail, and I did in fact mail my locking patches for the various NIC
> drivers to stable at .  In some cases I did only find testers via stable@ and
> not via current at .  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.

You said about testers, and testers are already involved somehow to the
project, at least are subscribed to lists. But testers are in general for
testing new features (positive), but not all FreeBSD users need new fetures
that fast. They are more concerned about feature removal (negative). Such
announcements need to be made at least for them to have migration plan - just
like Security Officer informs about EoL before that happens, for people have
time to plan maintenance and upgrade.

>>> If you wish to help work on ISDN support, I suggest you offer to test hps@'
>>> ISDN stack.  hps@ recently became a committer so I think there is a very good
>>> chance his code will be brought into the tree.
>>> We do have a policy for removing code in that it only gets removed if no one
>>> is able to maintain it and/or test patches for it.  I locked several of the
>>> remaining NIC drivers during the push to remove Giant and a few of them were
>>> removed from the system because no one had the hardware around to test the
>>> patches to add locking (think of really old ISA NICs that only do 10Mbps).
>> 
>> Big thanks for your work, but unfortunately, the problem itself is not ISDN or
>> network stack, it is deeper. It is the policy or may be style of thought,
>> discourse. Something like:
>>    progress dictates we need fix/maintainership to feature X
>>  & we have no resources to maintain feature X
>> -> we announce theis need, but only to _limited_ audience, not wide circles
>> -> nobody responds
>> -> the X code is removed
>> AND we think this logic chain is correct, thought we did not things this way
>> even 5 years ago.

> Actually, things have worked this way far longer than 5 years ago.  For
> example, 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).

Not entirely so. Individual drivers are more minor changes than major ones,
and still 5 years ago there were messages to announce@ about such removals
when there many-many of them, e.g. from Kris Kennaway.

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight at mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]