Index: head/en_US.ISO8859-1/htdocs/administration.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/administration.xml (revision 52829) +++ head/en_US.ISO8859-1/htdocs/administration.xml (revision 52830) @@ -1,517 +1,517 @@ ]>
This page lists teams, groups and individuals within the FreeBSD project with designated project roles and areas of responsibility, along with brief descriptions and contact information.
The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. The Core Team is elected by the active developers in the project.
The FreeBSD Documentation Engineering Team is responsible for defining and following up documentation goals for the committers in the Documentation project. The doceng team charter describes the duties and responsibilities of the Documentation Engineering Team in greater detail.
The primary responsibility of the FreeBSD Port Management Team is to ensure that the FreeBSD Ports Developer community provides a ports collection that is functional, stable, up-to-date and full-featured. Its secondary responsibility is to coordinate among the committers and developers who work on it. The portmgr team charter describes the duties and responsibilities of the Port Management Team in greater detail.
The Primary Release Engineering Team is responsible for setting and
publishing release schedules for official project releases of FreeBSD,
announcing code freezes and maintaining releng/* branches, among other
things. The release engineering team charter
describes the duties and responsibilities of the Primary Release
Engineering Team in greater detail.
The builders release engineering team is responsible for building and packaging FreeBSD releases on the various supported platforms.
The FreeBSD Donations Team is responsible for responding to donations offers, establishing donation guidelines and procedures, and coordinating donation offers with the FreeBSD developer community. A more detailed description of the duties of the Donations Team is available on the FreeBSD Donations Liaison page.
The FreeBSD Security Team (headed by the Security Officer) is responsible for keeping the community aware of bugs, exploits and security risks affecting the FreeBSD src and ports trees, and to promote and distribute information needed to safely run FreeBSD systems. Furthermore, it is responsible for resolving software bugs affecting the security of FreeBSD and issuing security advisories. The FreeBSD Security Officer Charter describes the duties and responsibilities of the Security Officer in greater detail.
Vendor Relations is responsible for handling email from hardware and software vendors. Email sent to Vendor Relations is forwarded to the &os; Core Team in addition to the &os; Foundation.
The &os; Core Team Secretary is a non-voting member of the Core Team, responsible for documenting the work done by core, keeping track of the core agenda, contacting non-core members on behalf of core, sending mail to core, and interfacing with the admin team for committer/account approval. The Core Team Secretary is also responsible for writing and sending out monthly status reports to the &os; Developer community, containing a summary of core's latest decisions and actions.
The FreeBSD Port Management Team Secretary is a non-voting member of the Port Management Team, responsible for documenting the work done by portmgr, keeping track of voting procedures, and to be an interface to the other teams, especially the admin and Core teams. The Port Management Team Secretary is also responsible for writing and sending out monthly status reports to the FreeBSD Developer community, containing a summary of portmgr's latest decisions and actions.
The Accounts Team is responsible for setting up accounts for new committers in the project. Requests for new accounts will not be acted upon without the proper approval from the appropriate entity.
Email sent to the Accounts Team is currently forwarded to the Cluster Administrators.
The Backups Administrators handle all backups on the FreeBSD cluster.
Email sent to the Backups Team is currently forwarded to the Cluster Administrators.
The Bugmeisters are responsible for ensuring that the problem report software is in working order, that the entries are correctly categorised and that there are no invalid entries.
The Cluster Administrators consists of the people responsible for maintaing the machines and services that the project relies on for its distributed work and communication. Issues concerning the projects infrastructure or setting up new machines should be directed to them. This team is led by the lead cluster administrator whose duties and responsbilities are described in the cluster administration charter in greater detail.
The DNS Administrators are responsible for managing DNS and related services.
E-mail to the DNS Administrators is currently forwarded to the Cluster Administrators.
The Forum Administrators maintain the &os; Project's Internet forum, located at https://forums.freebsd.org/ and lead the group of moderators who work to ensure the relevance and quality of the forum's content.
The GitHub Automation team oversees the export of &os; source code repository content to the read-only repository instances on GitHub
The Jenkins Administrators maintain the Continuous Integration and testing infrastructure for The &os; Project. This includes maintaining the Jenkins instance and the jobs that run builds and execute tests.
The FTP/WWW Mirror Site Coordinators coordinate all the FTP/WWW - mirror site adminstrators to ensure that they are distributing current + mirror site administrators to ensure that they are distributing current versions of the software, that they have the capacity to update themselves when major updates are in progress, and making it easy for the general public to find their closest FTP/WWW mirror.
E-mail to the Mirror Site Coordinators is currently forwarded to the Cluster Administrators with the addition of:
The Phabricator Administrators are responsible for maintaining the &os;'s instance of the Phabricator on-line code review tool located at https://reviews.freebsd.org/
For any problems regarding Phabricator, please open a bug report and select "Services" and then "Code Review".
The Postmaster Team is responsible for mail being correctly delivered to the committers' email address, ensuring that the mailing lists work, and should take measures against possible disruptions of project mail services, such as having troll-, spam- and virus-filters.
The FreeBSD Subversion team is responsible for maintaining the health of the Subversion Repositories.
Email to the Subversion Administration team is currently forwarded to the Cluster Administrators.
The FreeBSD Webmaster Team is appointed by &os; Documentation Engineering Team, and responsible for keeping the main FreeBSD web sites up and running. This means web server configuration, CGI scripts, fulltext and mailing list search. Anything web related, technical stuff belongs to the scope of the Webmaster Team, excluding bugs in the documentation.
Email to the Webmaster Team is currently forwarded to the Documentation Engineering team with the addition of:
The FreeBSD Wiki Team is responsible for keeping the FreeBSD Wiki site up and running. They also shape the overall design and content structure.
The Release Engineering Team has the following responsibilities :
Setting and publishing the release schedule for Official Project releases of FreeBSD.
Documenting and formalizing the RE procedures, so that the process can continually be reviewed and improved. This includes more documentation about the ports cluster and package split procedures.
Setting and publishing "Code Freeze" dates, and acting as a change-review committee to decide which changes may be made to a branch during a code freeze. This includes freezes for HEAD when approaching a .0 release as well as the traditional releng/* code freeze pending a -STABLE release.
Creation and maintenance of releng/* branches of the src/ tree. This includes final authority over what commits are made (and remain in) the -STABLE branch prior to the branching of a release branch.
Working with core and/or the FreeBSD Foundation to codify a set of guidelines that vendors must meet if they are to be allowed to call a product "FreeBSD", or an "Official FreeBSD release".
Testing and integrating required packages from the ports collection onto the official project release media. Portmgr@ is responsible for managing the ports/ code freeze and providing a complete package build of the re-distributable ports. re@ is then responsible for splitting those packages onto different ISOs as required by the release media. re@ is ultimately responsible for ensuring that all of the required packages are available on the FreeBSD release media, but portmgr@ cooperation is essential.
Coordinating with the FreeBSD Documentation Project, to ensure that a consistent set of documentation is provided for the release. This includes the ability to request that large disruptive changes not be made to the documentation set in the weeks leading up to a release.
Coordinating with the security officer team to ensure that pending FreeBSD releases are not affected by recently disclosed vulnerabilities. Also, approximately 1 week after a release, change approval control of release branches (releng/X.Y/) - is transfered from the release engineers to the security-officer + is transferred from the release engineers to the security-officer team. The exact transfer date is to be worked out by the two parties once it is clear that the release was a success. A heads up message should be sent to developers@ at that time.
Sending out messages to announce@FreeBSD.org on behalf of the project to announce new releases of FreeBSD.
FreeBSD takes security very seriously and its developers are constantly working on making the operating system as secure as possible. This page will provide information about what to do in the event of a security vulnerability affecting your system
FreeBSD security issues specific to the base system should be reported via email to the FreeBSD Security Team or, if a higher level of confidentiality is required, via PGP encrypted email to the Security Officer Team using the Security Officer PGP key. Additional information can be found at the reporting FreeBSD security incidents page.
A full list of all security vulnerabilities affecting the base system can be found on this page.
Advisories affecting the base system are sent to the following mailing lists:
The list of released advisories can be found on the FreeBSD Security Advisories page.
Advisories are always signed using the FreeBSD Security Officer PGP key and are archived, along with their associated patches, at the http://security.FreeBSD.org/ web server in the advisories and patches subdirectories.
The FreeBSD Security Officer provides security advisories for -STABLE Branches and the Security Branches. (Advisories are not issued for the -CURRENT Branch, which is primarily oriented towards &os; developers.)
The -STABLE branch tags have names like stable/10. The corresponding builds have names like FreeBSD 10.1-STABLE.
Each FreeBSD Release has an associated Security Branch. The Security Branch tags have names like releng/10.1. The corresponding builds have names like FreeBSD 10.1-RELEASE-p4.
Issues affecting the FreeBSD Ports Collection are covered separately in the FreeBSD VuXML document.
For users that have previously installed a binary version of &os; (e.g., &rel.current; or &rel2.current;), commands:
# freebsd-update fetchIf that fails, follow the other instructions in the security advisory you care about.
Note that the above procedure is only for users who have previously installed a binary distribution. Those who have built from source will need to update their source tree to upgrade.
Each release is supported by the Security Officer for a limited time only.
The designation and expected lifetime of all currently supported branches and their respective releases are given below. The Expected EoL (end-of-life) column indicates the earliest date on which support for that branch or release will end. Please note that these dates may be pushed back if circumstances warrant it.
Older releases are not supported and users are strongly encouraged to upgrade to one of these supported releases:
| Branch | Release | Type | Release Date | Expected EoL |
|---|---|---|---|---|
| stable/12 | n/a | n/a | n/a | June 30, 2020 (TBD) |
| releng/12.0 | 12.0-RELEASE | n/a | December 11, 2018 | 12.1-RELEASE + 3 months |
| stable/11 | n/a | n/a | n/a | September 30, 2021 |
| releng/11.2 | 11.2-RELEASE | n/a | June 28, 2018 | 11.3-RELEASE + 3 months |
In the run-up to a release, a number of -BETA and -RC releases may be published for testing purposes. These releases are only supported for a few weeks, as resources permit, and will not be listed as supported on this page. Users are strongly discouraged from running these releases on production systems.
Under the current support model, each major version's stable branch is explicitly supported for 5 years, while each individual point release is only supported for three months after the next point release.
The details and rationale behind this model can be found in the official announcement sent in February 2015.
Please note, the Core Team, in consultation with the Release Engineering, Security, and Port Manager teams, has decided that the FreeBSD Project needs to reevaluate the 5-year support guarantee along stable branches, starting with stable/12.
For more information, see the official - annoucement sent in November, 2018.
+ announcement sent in November, 2018.