FreeBSD Status Report Process


FreeBSD is a registered trademark of the FreeBSD Foundation.

Git and the Git logo are either registered trademarks or trademarks of Software Freedom Conservancy, Inc., corporate home of the Git Project, in the United States and/or other countries.

GitHub is a trademark of GitHub Inc., registered in the United States and other countries.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the “™” or the “®” symbol.

FreeBSD status reports are published quarterly and provide the general public with a view of what is going on in the Project, and they are often augmented by special reports from Developer Summits. As they are one of our most visible forms of communication, they are very important.

Throughout this document and in other places related to FreeBSD status reports as well, the expression status report is used both to indicate the document published on a quarterly basis and the single entries that are in it.

1. Instructions for writers

This section provides some advice on writing status report entries from David Chisnall, experienced in technical writing. Instructions on how to submit your entries are also given.

Do not worry if you are not a native English speaker. The status team will check your entries for spelling and grammar, and fix it for you.

1.1. Introduce Your Work

Do not assume that the person reading the report knows about your project.

The status reports have a wide distribution. They are often one of the top news items on the FreeBSD web site and are one of the first things that people will read if they want to know a bit about what FreeBSD is. Consider this example:

abc(4) support was added, including frobnicator compatibility.

Someone reading this, if they are familiar with UNIX man pages, will know that abc(4) is some kind of device. But why should the reader care? What kind of device is it? Compare with this version:

A new driver, abc(4), was added to the tree, bringing support for
Yoyodyne's range of Frobnicator network interfaces.

Now the reader knows that abc is a network interface driver. Even if they do not use any Yoyodyne products, you have communicated that FreeBSD’s support for network devices is improving.

1.2. Show the Importance of Your Work

Status reports are not just about telling everyone that things were done, they also need to explain why they were done.

Carry on with the previous example. Why is it interesting that we now support Yoyodyne Frobnicator cards? Are they widespread? Are they used in a specific popular device? Are they used in a particular niche where FreeBSD has (or would like to have) a presence? Are they the fastest network cards on the planet? Status reports often say things like this:

We imported Cyberdyne Systems T800 into the tree.

And then they stop. Maybe the reader is an avid Cyberdyne fan and knows what exciting new features the T800 brings. This is unlikely. It is far more likely that they have vaguely heard of whatever you have imported (especially into the ports tree: remember that there are over 30,000 other things there too…​). List some of the new features, or bug fixes. Tell them why it is a good thing that we have the new version.

1.3. Tell Us Something New

Do not recycle the same status report items.

Bear in mind that status reports are not just reports on the status of the project, they are reports on the change of status of the project. If there is an ongoing project, spend a couple of sentences introducing it, but then spend the rest of the report talking about the new work. What progress has been made since the last report? What is left to do? When is it likely to be finished (or, if "finished" does not really apply, when is it likely to be ready for wider use, for testing, for deployment in production, and so on)?

1.4. Sponsorship

Do not forget about your sponsors.

If you or your project has received sponsorship, a scholarship from somebody or you have been already working as a contractor or an employee for a company, please include it. Sponsors always certainly appreciate if you thank them for their funding, but it is also beneficial for them to show that they are actively supporting the Project this way. Last, but not least, this helps FreeBSD to learn more about its important consumers.

1.5. Open Items

If help is needed, make this explicit!

Is there any help needed with something? Are there tasks other people can do? There are two ways in which you can use the open items part of the status report: to solicit help, or to give a quick overview of the amount of work left. If there are already enough people working on the project, or it is in a state where adding more people would not speed it up, then the latter is better. Give some big work items that are in progress, and maybe indicate who is focussing on each one.

List tasks, with enough detail that people know if they are likely to be able to do them, and invite people to get in contact.

1.6. Submit your report

The following methods are available to submit your reports:

  • submit a Phabricator review and add the group status to the reviewers list. You should put your reports in the appropriate subdirectory of doc/website/content/en/status/ (create it if it is missing);

  • submit a pull request to the doc repository through its GitHub mirror . You should put your reports in the appropriate subdirectory of doc/website/content/en/status (create it if it is missing);

  • send an email to including your report.

2. Instructions for editors

This section describes how the reviewing and publication process works.

Status reports main webpage

Status reports archived GitHub repository (was used for reports from 2017Q4 to 2022Q4):

Main status team email address

Email address for reports submission

Mailing list for receiving calls for status reports

Phabricator status team main page

2.1. Timeline

Reports are always accepted by the status team, but the main collection process happens the last month of each quarter, hence in March, June, September and December. Explicit calls for status reports will be sent in those months. The months of January, April, July and October are dedicated to putting together the reports submitted during the precedent quarter; this can include waiting for late submissions. Status reports publication is done during the same months as soon as the report are ready.

All report submissions can have the deadline extended by emailing the status team up until the extended deadline, which is 8 days after the end of the quarter. Entries from the ports management team default to the extended headline, because of the overlap between status reports and quarterly ports branches.

Reviewing of submitted reports by people not part of the status team should be essentially complete by mid-January/April/July/October (third-party review slush). That is, barring typos or other light copyediting, the status team should be able to start assembling the submissions soon after the 15th. Note that this is not a complete freeze, and the status team may still be able to accept reviews then.

First quarterSecond quarterThird quarterFourth quarter

First call for reports

March 1st

June 1st

September 1st

December 1st

2 weeks left reminder

March 15th

June 15th

September 15th

December 15th

Last reminder

March 24th

June 24th

September 24th

December 24th

Standard deadline

March 31st

June 30th

September 30th

December 31st

Extended deadline

April 8th

July 8th

October 8th

January 8th

Third-party review slush

April 15th

July 15th

October 15th

January 15th

2.2. Call for reports

Calls for status reports are sent to the following recipients:

  • the mailing list;

  • to all submitters of last status reports (they may have updates or further improvements);

  • and, depending on the season:

    • Various conference organizers:

      • AsiaBSDCon in March (First Quarter);

      • BSDCan in May (Second Quarter);

      • EuroBSDcon September - October (Third-Fourth Quarter). EuroBSDcon as an organization is not interested in writing reports for FreeBSD (at least it was not in October 2019: its reason is that the conference is not FreeBSD specific), so reports about this event should be asked of members of the FreeBSD community that attended it;

    • Google Summer of Code students and their mentors.

The easiest way to send calls for status reports is to use the sendcalls perl script in the tools/sendcalls directory of the doc git repository. The script automatically sends calls to all intended recipients. It can also be used through a cron job, for example:

0      0       1,15,24 3,6,9,12        *       cd ~/doc/tools/sendcalls && git pull && ./sendcalls -s 'Lorenzo Salvadore'

If you are in charge of sending calls for status reports and you are indeed using a cron job, please run it on freefall and sign it with your name so that it is possible to infer who has configured the cronjob, in case something goes wrong. Also please update the example above with your name, as an additional safety measure.

It may also be worth making a call for reports on the forums as was done in the past.

2.3. Building the report

Submitted reports are reviewed and merged in the proper subdirectory of doc/website/content/en/status/ as they come in. While the reports are being updated, people outside the status team may also review the individual entries and propose fixes.

Usually the last step in the content review process is writing the introduction in a file named intro.adoc: a good introduction can only be written once all the reports have been collected. If possible, it is a good idea to ask different people to write the introduction to add variety: different people will bring different viewpoints and help keep it fresh.

Once all the reports and the introduction are ready, the _index.adoc file needs to be created: this is the file in which the reports are distributed into the various categories and sorted.

2.4. Publishing the report

When all the files of the status report are ready, it is time to publish it.

First doc/website/content/en/status/_index.adoc is edited: the next due date is updated and a link to the new report is added. The change is then pushed on the repository and the status team checks that everythings works as expected.

Then the news entry for the main website page is added to doc/website/data/en/news/news.toml.

Here is a sample for the news entry:

date = "2021-01-16"
title = "October-December 2020 Status Report"
description = "The <a href=\"\">October to December 2020 Status Report</a> is now available with 42 entries."

Once the HTML version of the report has been built and is online, w3m(1) is used to dump the website as plain-text, e.g:

% w3m -cols 80 -dump > /tmp/report-2021-01-2021-03.txt

w3m(1) has full proper unicode support. -dump simply outputs text rendering of the HTML code that can then have a few elements snipped, while -cols ensures that everything is wrapped to 80 columns.

A link to the rendered report is added between the introduction and the first entry.

The report is finally ready to be sent, toggling disposition (the report should be inlined), and ensuring it is encoded as UTF-8.

Two emails are sent, both with subject in the format FreeBSD Status Report - <First/Second/Third/Fourth> Quarter <year>:

This one must be approved, so if you are in charge of sending this email, ensure that someone does it (mail postmaster if it is taking long).

Last modified on: March 14, 2023 by Lorenzo Salvadore