The &os; Core Team

From owner-svn-doc-head@FreeBSD.ORG Wed Apr 15 04:12:20 2015 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C01A0C57; Wed, 15 Apr 2015 04:12:20 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A19E15EE; Wed, 15 Apr 2015 04:12:20 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id t3F4CKuU008733; Wed, 15 Apr 2015 04:12:20 GMT (envelope-from bjk@FreeBSD.org) Received: (from bjk@localhost) by svn.freebsd.org (8.14.9/8.14.9/Submit) id t3F4CKNI008732; Wed, 15 Apr 2015 04:12:20 GMT (envelope-from bjk@FreeBSD.org) Message-Id: <201504150412.t3F4CKNI008732@svn.freebsd.org> X-Authentication-Warning: svn.freebsd.org: bjk set sender to bjk@FreeBSD.org using -f From: Benjamin Kaduk Date: Wed, 15 Apr 2015 04:12:20 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r46556 - head/en_US.ISO8859-1/htdocs/news/status X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 04:12:21 -0000 Author: bjk Date: Wed Apr 15 04:12:19 2015 New Revision: 46556 URL: https://svnweb.freebsd.org/changeset/doc/46556 Log: Add core team report Approved by: hrs (mentor, implicit) Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml Wed Apr 15 04:06:30 2015 (r46555) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml Wed Apr 15 04:12:19 2015 (r46556) @@ -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.

+ +