Re: Code removal - Was Re: Future of the ie(4) driver

Julian H. Stacey wrote:
> John Baldwin wrote:
>> The ie(4) driver in 7.x has several issues.  First of all, it has several 
>> compiler warnings that haven't been successfully fixed in several years and 
>> are currently just ignored.  More importantly, it hasn't been updated to use 
>> more modern FreeBSD APIs like bus_space (still uses inb/outb) and SMPng 
>> locking.  If someone is using this driver and is willing to test fixes for 
>> it, then it can be updated.  If there isn't anyone who is using this driver 
>> and willing to test fixes, then it will be removed from the tree at some 
>> point in the future (say a month or two).
> 
> I reduced "cc: stable_at_freebsd.org, current_at_freebsd.org" to current_at_
> & changed "Subject:" so as not to cross post this tangential reply.
>   ( BTW I checked, I don't have any hardware that uses "ie" )
> 
> What's concerned me increasingly for some time, (& nothing personal
> to any individual, (the above just a useful illustration ) is a
> tendency in FreeBSD for developers to say:
> 	~Unless anyone speaks in [time] I will discard [whatever]~
> Then months later a new release is rolled, & months later users upgrade, &:
> 	"Oh my god! they removed the XYZ I use ! ... Aargh!~
>

Actually, most developers use pretty good judgment in this area.  These
aren't PCI drivers or otherwise highly active parts that are being
retired, these are pieces of code for 15 year old hardware that have
been unloved and unmaintained for years.  No one is talking about
dropping previous generation devices here, and the only reason it's
being talked now about is because the neglect shown towards it over the
years stands out more than most others.  In this case and as well as
previous cases, great efforts are made to reach out to the community to
get help with testing and maintainership.  If those requests go
unanswered, then what else should the developers do?  Participation is
key to the ongoing success of the project, plain and simple.

> So when discarding, it seems best to adopt a policy to warn as
> wide a user base as possible, not just developers.  
>    Not just current_at_ or stable_at_ but at least all of hackers_at_.
> 
>    Even then we risk hurting happy users of FreeBSD, eg
>    ISPs etc who just don't have time to read hackers_at_ every day.
> 
>    Maybe FreeBSD should have a low bandwidth mail list, that managers
>    & busy admins could safely subscribe, so they get long warning
>    of functional removal ? Such things as eg 16 bit PCMCIA removal
>    (after 4.11 before 6.*) would have gone to such a list, etc.
> 
> Good PR to keep wider user base informed of planned removals,
> & some otherwise unknowing users might then reply 
> 	"OK, I'll install current/ stable on a spare box, & give
> 	developer(s) access, as I can't afford to lose functionality~
> 
> PS Analogy: 
>   Opening programme in the "Hitch Hikers Guide To The Galaxy":
>     The plan to demolish Arthur's house. on display in locked basement,
>     The plan to demolish Earth, only filed on Alpha Centauri :-)

Hatching and then executing a plan on IRC or a private developer mailing
list or in the terminal room of a conference would be a good analogy.
Announcing the plan to a public mailing list and asking for help is NOT,
I repeat, NOT, a good analogy.  There are no unlit stairs or leopards
waiting behind lavatory doors keeping poor if_ie users from
participating on the current_at_ mailing list.  As long as it stays that
way, I think we have a pretty decent system.

Scott