Add core team report

Approved by:	hrs (mentor, implicit)
This commit is contained in:
Benjamin Kaduk 2015-04-15 04:12:19 +00:00
parent 5faf7f2a76
commit f27f5b0759
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=46556

View file

@ -2071,4 +2071,59 @@ WITHOUT_FORTH=y</pre>
</task>
</help>
</project>
<project cat='team'>
<title>The &os; Core Team</title>
<contact>
<person>
<name>&os; Core Team</name>
<email>core@FreeBSD.org</email>
</person>
</contact>
<body>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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?</p>
<p>During this quarter five new src commit bits were granted and
two were taken in for safe-keeping.</p>
</body>
</project>
</report>