Mark Johnston
2021-03-28 00:23:13 UTC
Dear FreeBSD Community,
In light of the recent commentary on FreeBSD's development practices,
members of the Core team would like to issue the following statement.
Code quality is an essential FreeBSD value: From the 1980s when work on
BSD became the de facto standard TCP/IP stack, to our more recent work
around performance scalability on multicore, attention to detail is
critical. The recent concerns regarding the WireGuard patches remind us
that our development processes must always continue to mature. While the
project has historically, and aggressively, led the way in adopting new
development methodologies - from public version control to being early
adopters of static analysis tools such as Coverity - these events have
brought to light a real gap that needs to be addressed.
The high stability and quality of FreeBSD is a testimony to the
experience of our developers. As in any open source project, we rely on
developers to exercise good judgement in seeking review and committing
new features, and to follow the guidelines laid out in the Committer's
Guide. We make heavy use of public code review, and FreeBSD developers
spend a significant amount of time improving each others' contributions.
We were excited to provide a kernel WireGuard implementation in FreeBSD
13.0. Before the if_wg(4) rewrite was committed, several FreeBSD
developers proactively worked on fixing bugs and writing tests and
documentation for the original implementation. In other words, we had
spent time during the release's Q/A period looking for problems, and
that unfortunately culminated in if_wg(4) being removed from 13.0 during
the release cycle. As FreeBSD developers, it is incumbent on each of us
to support each other's work by providing code review and helping test
and fix the code. This incident highlights the need to do this work more
proactively, and to maintain a robust, multi-layered development process
that can catch problems as they fall through the cracks.
Over the next month the FreeBSD Core Team will lead a discussion on
appropriate pre-commit testing, static analysis, code review, and
integration policies to avoid a repeat of this situation and to continue
improving FreeBSD's code quality. We know there will be challenges in
key areas, such as third-party device drivers, and components of the
system where fewer developers have sufficient expertise. The FreeBSD
Foundation has full-time staff members participating in significant code
review today, and is committed to supporting the needs identified by the
Core team and the developer community for this effort.
We look forward to input from the community on our proposals for updated
policies as we move forward, maintaining high code quality as a core
value for FreeBSD.
Thanks,
-Mark, with core@ hat on
In light of the recent commentary on FreeBSD's development practices,
members of the Core team would like to issue the following statement.
Code quality is an essential FreeBSD value: From the 1980s when work on
BSD became the de facto standard TCP/IP stack, to our more recent work
around performance scalability on multicore, attention to detail is
critical. The recent concerns regarding the WireGuard patches remind us
that our development processes must always continue to mature. While the
project has historically, and aggressively, led the way in adopting new
development methodologies - from public version control to being early
adopters of static analysis tools such as Coverity - these events have
brought to light a real gap that needs to be addressed.
The high stability and quality of FreeBSD is a testimony to the
experience of our developers. As in any open source project, we rely on
developers to exercise good judgement in seeking review and committing
new features, and to follow the guidelines laid out in the Committer's
Guide. We make heavy use of public code review, and FreeBSD developers
spend a significant amount of time improving each others' contributions.
We were excited to provide a kernel WireGuard implementation in FreeBSD
13.0. Before the if_wg(4) rewrite was committed, several FreeBSD
developers proactively worked on fixing bugs and writing tests and
documentation for the original implementation. In other words, we had
spent time during the release's Q/A period looking for problems, and
that unfortunately culminated in if_wg(4) being removed from 13.0 during
the release cycle. As FreeBSD developers, it is incumbent on each of us
to support each other's work by providing code review and helping test
and fix the code. This incident highlights the need to do this work more
proactively, and to maintain a robust, multi-layered development process
that can catch problems as they fall through the cracks.
Over the next month the FreeBSD Core Team will lead a discussion on
appropriate pre-commit testing, static analysis, code review, and
integration policies to avoid a repeat of this situation and to continue
improving FreeBSD's code quality. We know there will be challenges in
key areas, such as third-party device drivers, and components of the
system where fewer developers have sufficient expertise. The FreeBSD
Foundation has full-time staff members participating in significant code
review today, and is committed to supporting the needs identified by the
Core team and the developer community for this effort.
We look forward to input from the community on our proposals for updated
policies as we move forward, maintaining high code quality as a core
value for FreeBSD.
Thanks,
-Mark, with core@ hat on