diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml b/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml index 376c4957ac..abee98050f 100644 --- a/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml +++ b/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml @@ -2071,4 +2071,59 @@ WITHOUT_FORTH=y + + + The &os; Core Team + + + + &os; Core Team + core@FreeBSD.org + + + + +

The &os; 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 &os; + project landscape.

+ +

January began with members of core dealing with the fallout + from the accidental deletion of the Bugzilla database. This + incident highlighted the fact that backup and recovery mechanisms + in the cluster were not up to the task. Core has discussed what + measures are appropriate with clusteradm and is reviewing their + implementation.

+ +

After a long process of consultation, plans for introducing the + new support model with 11.0-RELEASE were finally agreed on and + published in early February. This announcement puts the practical + detail onto the motion that was adopted at BSDCan 2014, and + clarifies the steps needed for implementation.

+ +

Also in February core revisited discussions on making the + blogs.freebsdish.org blog aggregator an official project service + and also providing a blogging platform directly to developers. + However, security and man-power are both major concerns. Given + the track records of most freely available blogging platforms, + core is rightly wary of introducing them into the cluster. + Similarly, curating a bloging platform will take a substantial + volunteer effort to ensure all posts are appropriate and to remove + spam.

+ +

March has seen two discussions about potentially divisive + topics. Should the ZFS ARC Responsiveness patches be committed + and MFC'd as a pragmatic fix to performance problems in + 10.1-RELEASE, understanding that this is not an ideal solution to + the problem and will need rework? Should we stop maintaining + support for older (C89 or earlier) compilers in kernel code, and + just code directly to the C11 standard? Broadening out from this + last point: should we have a formal mechanism for deciding what + has become obsolete in the system and when it should be + removed?

+ +

During this quarter five new src commit bits were granted and + two were taken in for safe-keeping.

+ +