FreeBSD Developer Summit: Clearing Deadwood
Schedule: TBD
Session chair: BrooksDavis brooks@
Overview
FreeBSD endeavors to support a broad range of modern hardware and provide long-term support for software. Each platform, device driver, and subsystem has an ongoing maintenance cost so we periodically remove codebases that have few or no users (e.g. Alpha, Itanium, the EISA bus). This deadwood removal is necessary for the project to survive. Unfortunately, we aren't very good at it. We leave things in the tree after their expiration dates (e.g. token ring support was removed long after the last device driver) and we delete things without sufficient notice. This working group aims to improve out processes around deprecation and deletion.
This working group is not a torch and pitchfork party where we delete things or make lists of things to delete.
If you would like to participate, contact the working group chairs below and CC devsummit@. You will be then added to this page. Please include a list of things you want to talk about or the areas you are interested in. This helps us in planning the session and to bring people together with common interests.
It is possible to bring in people who cannot attend in person via video conference or chat tools. Notes during the session will be published later on for the whole community to see what we discussed.
Goals
In particular, we would like to cover the following topics. This is not an exhaustive list and if you feel there is something missing that you want to talk about, contact one of the session chairs and we will include your topic here. Note that the numbering of the topics does not represent an ordering or importance indication of any kind, but rather a reference to the second table with the "topic of interest" column.
Topics
# |
Topic Description |
1 |
Deprecation policy (see 17.4 in The FreeBSD Committers Big List of Rules) |
1.1 |
Ideal deprecation workflow |
1.2 |
Exceptions to ideal workflow |
2 |
Reviewing the tree for deadwood |
2.1 |
What to review? (Types of subsystems, etc) |
2.2 |
Data to support reviews. |
2.3 |
When to review? |
2.4 |
What are the criteria for removing something? (Availability, installed base, age of hardware, bus technology, code ownership, code quality...) |
Attending
In order to attend you need register for the developer summit as well as by email for the session and be confirmed by the working group organizer. Follow the guidelines described on the main page or what you received by email. For questions or if in doubt ask the session chairs.
Please DO add yourself here and email the session chair if you plan to attend.
# |
Name |
Username / Affiliation |
Topics of Interest |
Notes |
1 |
brooks |
* |
Session chair |
|
2 |
imp |
* |
Ax-wielding non-dane |
|
3 |
mwlucas |
* |
Obituary writer |
|
4 |
mckusick |
* |
Lumberjack |
|
5 |
jtl |
* |
Chainsaw owner |
Results
Questions we need to answer
What is the scope of the FreeBSD project? What are we trying to accomplish?
How do we get data to decide that something's not used any more? (dmesgd, bsdstats)
How do we determine the cost of maintaining a piece of code? How many patches are done only to avoid breakage after API/ABI changes? How many people understand it?
Questions to weigh when evaluating keeping or reming something
- Relevant technology, for which we have users.
- Do we have users?
- Will there be new users?
- Is there someone maintaining it?
- How many special cases are there for this thing?
- Is it broken? (How long can it be broken before people notice?)
- Is the hardware still being made or emulated?
Classes of things that need periodic review
- architectures
- drivers
- technology stacks (e.g. arcnet, pci, isa, ...)
- legacy software interfaces/APIs (e.g. debugging through procfs, sbrk())
- software features
Specific criteria proposal
- does it work? Does it work well?
- commit metadata to add:
- fix vs. feature
- improving the driver vs. maintenance
- device availability
- Can you buy it?
- how many are out there? (Is it popular?)
- Can users run modern FreeBSD?
- bug reports, dmesgd, bsdstats
- developer feedback: what is it preventing?
- Can you replace it?
- Do systems meet minimal spec? (needs update, Warner notes that the kernel grew by 33% for decades)
List of things to review once we have policies
- parallel SCSI
- 10/100 Ethernet
- ISA add-in cards (soundblaster?)
- sparc64
- arm v4/v5
- mips32 (for 13)
- 486 core support
- powerpc32
- sound drivers
- one-off geom classes (geom bsd)
- TV tuner drivers
- pre-standard wifi drivers (aeronet, wi)
- raid cards (pre-cam, 3ware, ida)
- PCCard / Cardbus
- syscons
- sio
- unionfs
- ipf
Action Items
- Scope of FreeBSD
Deprecation guidelines (general and by class) WarnerLosh
- Datamine bsdstats or dmesgd
- Proposal for commit marking