svn commit: r48066 - head/en_US.ISO8859-1/htdocs/news/status
Benjamin Kaduk
bjk at FreeBSD.org
Tue Jan 19 03:16:58 UTC 2016
Author: bjk
Date: Tue Jan 19 03:16:56 2016
New Revision: 48066
URL: https://svnweb.freebsd.org/changeset/doc/48066
Log:
Partially restructure the core team report
Split out the two major issues into enumerated portions for greater
clarity. Reorder content within the security team reorganization portion
of the entry in order to make more prominent the actual nature of the
restructuring, and improve clarity on the motivation and ramifications
of the changes.
Discussed with: koobs
Modified:
head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml
Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml
==============================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml Tue Jan 19 02:46:19 2016 (r48065)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml Tue Jan 19 03:16:56 2016 (r48066)
@@ -2483,68 +2483,81 @@
</contact>
<body>
- <p>Two major concerns have occupied much of core's attention
+ <p>Two major issues have occupied much of core's attention
during the last quarter: the reorganisation of the Security
Team and the question of whether to import GPLv3 licensed code
into the source repository.</p>
- <p>The Security Team reorganisation, first proposed to Core
- during a meeting at BSDCan this year by Gleb Smirnoff — core
- member and newly-appointed deputy Security Officer (SO) — has now
- been accomplished. In order to improve the project's
- responsiveness to security alerts, to maintain security on
- privileged information received in confidence before general
- publication and, not least, to reduce the work load on the
- security officer, the role of the SO team has been redefined as
- the controller of the distribution of security sensitive
- information within the project; they are responsible for
- interfacing with external bodies and individuals reporting
- security problems, and connecting them with appropriate
- individuals within the project with the technical expertise to
- address the identified concerns. The SO team was cut down to just
- the Security Officer and their deputy, assisted by a secretary, and
- with input and help in drafting security advisories from former
- and any potential future Security Officers plus liasons with Core,
- Cluster Administration and Release Engineering.</p>
-
- <p>Core would particularly like to thank the former members of
- the Security Team group for their past contributions, now that
- the Security Team role has been merged into the Security
- Officer's responsibilities.</p>
-
- <p>The other large question concerning Core is how to provide a
- modern toolchain for all supported achitectures. Tier 1
- architectures are required to ship with a toolchain
- unencumbered by onerous license terms. This is currently
- provided for i386 and arm64 by the LLVM suite, including the
- Clang compiler, LLD and LLDB. However LLVM support for other
- (Tier 2 or below) architectures is not yet of sufficient quality
- to be viable, and the older but pre-existing GPLv2 toolchain
- cannot support some of the interesting new architectures such
- as arm64 and RISC V. Pragmatically, in order for the project
- to support these, until LLVM support arrives we must turn to the
- GNU project's GPLv3 licenced toolchain.</p>
-
- <p>The argument here is whether to import GPLv3 licensed code
- into the &os; src repository with all of the obligations on
- patent terms and source code redistribution that would entail,
- not only for the &os; project itself but for numerous
- downstream consumers of &os; code. Not having a toolchain
- readily available is a big impediment to working on a new
- architecture.</p>
+ <ol>
+ <li>
+ <p>The idea of reorganizing the Security team was first
+ proposed to Core during a meeting at BSDCan this year by
+ Gleb Smirnoff — core member and newly-appointed deputy
+ Security Officer (SO). The "Security Team", which
+ previously could contain several people (a varying number
+ over time, but more than two) has been refashioned into just
+ two roles: Security Officer and Deputy Security Officer.
+ Accordingly, the role of the SO team has been redefined to
+ be the controller of the distribution of security sensitive
+ information into and within the project; they are
+ responsible for interfacing with external bodies and
+ individuals reporting security problems to the project, and
+ connecting those reports to the appropriate individuals
+ within the project with the technical expertise to address
+ the identified concerns. These changes will improve the
+ project's responsiveness to security alerts, help maintain
+ security on privileged information received in confidence
+ before general publication and, not least, reduce the work
+ load on the security officer. The SO team will continue to
+ benefit from liasons with the Core, Cluster Administration,
+ and Release Engineering teams, and will be assisted by a
+ secretary; they will also be able to obtain input and
+ assistance in drafting security advisories from former and
+ potential future (Deputy) Security Officers.</p>
+
+ <p>Core would particularly like to thank the
+ former members of the Security Team group for their past
+ contributions, now that the Security Team role has been
+ merged into the Security Officer's responsibilities.</p>
+ </li>
- <p>One potential solution is to create a range of "GPLv3
- toolchain" base-system packages out of a completely separate
- source code repository, for instance within the &os; area on
- Github. These would be distributed equivalently to the other
- base system binary packages when that mechanism is
- introduced.</p>
-
- <p>Core recognises that this is a decision with wide-ranging
- consequences and will be producing a position paper for
- circulation amongst all interested parties in order to judge
- community opinion on the matter. Core welcomes feedback from
- all interested parties on the subject.</p>
+ <li>
+ <p>The other large question concerning Core is how to provide a
+ modern toolchain for all supported achitectures. Tier 1
+ architectures are required to ship with a toolchain
+ unencumbered by onerous license terms. This is currently
+ provided for i386 and arm64 by the LLVM suite, including the
+ Clang compiler, LLD and LLDB. However LLVM support for
+ other (Tier 2 or below) architectures is not yet of
+ sufficient quality to be viable, and the older but
+ pre-existing GPLv2 toolchain cannot support some of the
+ interesting new architectures such as arm64 and RISC V.
+ Pragmatically, in order for the project to support these,
+ until LLVM support arrives we must turn to the GNU project's
+ GPLv3 licenced toolchain.</p>
+
+ <p>The argument here is whether to import GPLv3 licensed code
+ into the &os; src repository with all of the obligations on
+ patent terms and source code redistribution that would entail,
+ not only for the &os; project itself but for numerous
+ downstream consumers of &os; code. Not having a toolchain
+ readily available is a big impediment to working on a new
+ architecture.</p>
+
+ <p>One potential solution is to create a range of "GPLv3
+ toolchain" base-system packages out of a completely separate
+ source code repository, for instance within the &os; area on
+ Github. These would be distributed equivalently to the other
+ base system binary packages when that mechanism is
+ introduced.</p>
+
+ <p>Core recognises that this is a decision with wide-ranging
+ consequences and will be producing a position paper for
+ circulation amongst all interested parties in order to judge
+ community opinion on the matter. Core welcomes feedback from
+ all interested parties on the subject.</p>
+ </li>
+ </ol>
<p>Beyond these two big questions, Core has handled a number of
lesser items:</p>
More information about the svn-doc-all
mailing list