svn commit: r48132 - head/en_US.ISO8859-1/htdocs/news/status

Warren Block wblock at FreeBSD.org
Sun Jan 31 21:51:41 UTC 2016


Author: wblock
Date: Sun Jan 31 21:51:40 2016
New Revision: 48132
URL: https://svnweb.freebsd.org/changeset/doc/48132

Log:
  Editing pass.  Yes, I changed stuff.  It got a bit weird with the time
  travel in the third act, and the whole car chase scene did not make
  sense.

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	Sun Jan 31 16:30:18 2016	(r48131)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml	Sun Jan 31 21:51:40 2016	(r48132)
@@ -104,7 +104,7 @@
       <p>LKL ("Linux Kernel as a Library") is a special
 	"architecture" of the full Linux kernel that builds as a
 	userspace library on various platforms, including &os;.  One
-	application of such a library is using Linux's filesystem drivers
+	application of such a library is using Linux filesystem drivers
 	to implement a FUSE backend.</p>
 
       <p>fusefs-lkl's <tt>lklfuse</tt> binary is such a FUSE
@@ -112,14 +112,14 @@
 	<tt>BTRFS</tt> read-write, using the native drivers from
 	Linux.</p>
 
-      <p>The <tt>sysutils/fusefs-lkl</tt> port may now be installed from
+      <p><tt>sysutils/fusefs-lkl</tt> can now be installed either from
 	packages or ports, providing access to these filesystems on
 	&os; via FUSE.</p>
     </body>
   </project>
 
   <project cat='doc'>
-    <title>Style(9) enhanced to allow C99 'bool'</title>
+    <title><tt>style(9)</tt> Enhanced to Allow C99 <tt>bool</tt></title>
 
     <contact>
       <person>
@@ -146,7 +146,7 @@
 
     <body>
       <p>Use of <tt>bool</tt> is now allowed.  It was allowed
-	previously, as well, but now it's <em>really</em> allowed.  Party
+	previously, as well, but now it is <em>really</em> allowed.  Party
 	like it's 1999!</p>
     </body>
 
@@ -167,7 +167,7 @@
   </project>
 
   <project cat='kern'>
-    <title>Sysctl enhancements</title>
+    <title><tt>sysctl</tt> Enhancements</title>
 
     <contact>
       <person>
@@ -201,13 +201,13 @@
     </links>
 
     <body>
-      <p> This quarter, support was added for fixed-width sysctls
+      <p>Support was added for fixed-width sysctls
 	(signed and unsigned 8-bit, 16-bit, 32-bit, and 64-bit integers).
 	The new KPIs are documented in the <tt>sysctl(9)</tt> manual page.
 	The <tt>sysctl(8)</tt> command line tool supports all of the new
 	types.</p>
 
-      <p><tt>sysctl(8)</tt> gained the '-t' flag, which prints sysctl type
+      <p><tt>sysctl(8)</tt> gained the <tt>-t</tt> flag, which prints sysctl type
 	information (the original patch was submitted by Yoshihiro Ota).
 	This support includes the newly added fixed-width types.</p>
     </body>
@@ -218,7 +218,7 @@
   </project>
 
   <project cat='kern'>
-    <title>ioat(4) driver enhancements</title>
+    <title><tt>ioat(4)</tt> Driver Enhancements</title>
 
     <contact>
       <person>
@@ -240,8 +240,8 @@
 	engines built into some Intel Server/Storage platform
 	CPUs.</p>
 
-      <p>This quarter, several enhancements were made to the driver.
-	The driver now avoids memory allocation in locked paths, which
+      <p>Several enhancements were made to the driver.
+	It now avoids memory allocation in locked paths, which
 	should avoid deadlocking in memory pressure scenarios.  Support
 	for Broadwell-EP devices has been added.  The
 	"blockfill" operation and a non-contiguous 8 KB copy
@@ -261,7 +261,7 @@
   </project>
 
   <project cat='kern'>
-    <title>ntb_hw(4)/if_ntb(4) driver synced up to Linux</title>
+    <title><tt>ntb_hw(4)</tt>/<tt>if_ntb(4)</tt> Driver Synced up to Linux</title>
 
     <contact>
       <person>
@@ -311,7 +311,7 @@
   </project>
 
   <project cat='arch'>
-    <title>&os; on newer ARM boards</title>
+    <title>&os; on Newer ARM Boards</title>
 
     <contact>
       <person>
@@ -337,9 +337,9 @@
     </links>
 
     <body>
-      <p>This quarter, we made the changes necessary to support the
+      <p>We made the changes required to support the
 	Amlogic Meson Ethernet controller on the Hardkernel ODROID-C1
-	board which has an Amlogic aml8726-m8b SoC.  The main effort
+	board, which has an Amlogic aml8726-m8b SoC.  The main effort
 	needed was to write a glue driver for the Ethernet controller
 	— the Amlogic Meson Ethernet controller is compatible with
 	Synopsys DesignWare 10/100/1000 Ethernet MAC
@@ -387,7 +387,7 @@
   </project>
 
   <project cat='doc'>
-    <title>"FreeBSD Mastery: Specialty Filesystems" early access version now available</title>
+    <title>"FreeBSD Mastery: Specialty Filesystems" Early Access Version Now Available</title>
 
     <contact>
       <person>
@@ -413,7 +413,7 @@
 	NFSv4 ACLs, iSCSI, CIFS, and more.</p>
 
       <p>If you act really quickly, you can get the electronic early
-	access version at a 10% discount.  You'll get the final ebook when
+	access version at a 10% discount.  You will get the final ebook when
 	it comes out as well. (This offer evaporates when the final
 	version comes out.)</p>
     </body>
@@ -437,10 +437,10 @@
     </links>
 
     <body>
-      <p>The KGDB option is now on by default in the devel/gdb
+      <p>The KGDB option is now on by default in the <tt>devel/gdb</tt>
 	port.</p>
 
-      <p>The changes to support cross-debugging of crashdumps in
+      <p>Changes to support cross-debugging of crashdumps in
 	libkvm were committed to HEAD in r291406.</p>
 
       <p>A new thread target for &os; that is suitable for merging
@@ -479,7 +479,7 @@
   </project>
 
   <project cat='kern'>
-    <title>iMX.6 video output support</title>
+    <title>iMX.6 Video Output Support</title>
 
     <contact>
       <person>
@@ -521,7 +521,7 @@
   </project>
 
   <project cat='kern'>
-    <title>Touchscreen support for Raspberry Pi and Beaglebone Black</title>
+    <title>Touchscreen Support for Raspberry Pi and Beaglebone Black</title>
 
     <contact>
       <person>
@@ -614,7 +614,7 @@
 	vnodes.</p>
 
       <p>Vnode cache recycling was reworked to meet free and unused
-	vnodes targets.  Free vnodes are rarely completely free; rather,
+	vnode targets.  Free vnodes are rarely completely free; rather,
 	they are just ones that are cheap to recycle.  Usually they are
 	for files which have been stat'd but not read; these usually have
 	inode and namecache data attached to them.  The free vnode target
@@ -631,18 +631,18 @@
 	recycling from the free list and normal use maintains this state.
 	Sometimes the free list is below vlowat or even empty, but this
 	state is even better for immediate use, provided the cache is not
-	full.  Otherwise, vnlru_proc() runs to reclaim enough vnodes
+	full.  Otherwise, <tt>vnlru_proc()</tt> runs to reclaim enough vnodes
 	(usually non-free ones) to reach one of these states.  The
 	watermarks are currently hard-coded as 4% and 9% of the available
 	space.  These, and the default of 25% for wantfreevnodes, are too
-	large if the memory size is large.  E.g., 9% of 75% of MAXVNODES
-	is more than 566000 vnodes to reclaim whenever vnlru_proc()
+	large if the memory size is large.  For example, 9% of 75% of MAXVNODES
+	is more than 566000 vnodes to reclaim whenever <tt>vnlru_proc()</tt>
 	becomes active.</p>
 
       <p>The <tt>vfs.vlru_alloc_cache_src</tt> sysctl is removed.
 	New code frees namecache sources as the last chance to satisfy the
 	highest watermark, instead of selecting source vnodes randomly.
-	This provides good enough behaviour to keep vn_fullpath() working
+	This provides good enough behavior to keep <tt>vn_fullpath()</tt> working
 	in most situations.  Filesystem layouts with deep trees, where the
 	removed knob was required, is thus handled automatically.</p>
 
@@ -661,14 +661,14 @@
 	times at system startup, and then only rarely again.  The frees
 	are done only if the vnode zone shrinks, which never happens in
 	practice.  For those curious about the avoided work, look at the
-	vnode_init() and vnode_fini() functions in sys/kern/vfs_subr.c to
+	<tt>vnode_init()</tt> and <tt>vnode_fini()</tt> functions in sys/kern/vfs_subr.c to
 	see the code that has been removed from the main vnode
 	allocation/free path.</p>
     </body>
   </project>
 
   <project cat='kern'>
-    <title>Improvements to QLogic HBA driver</title>
+    <title>Improvements to the QLogic HBA Driver</title>
 
     <contact>
       <person>
@@ -681,8 +681,8 @@
     </contact>
 
     <body>
-      <p>The QLogic HBA driver <tt>isp(4)</tt> received a
-	substantial set of changes.  Their primary goal was to make Fibre
+      <p>The QLogic HBA driver, <tt>isp(4)</tt>, received a
+	substantial set of changes.  The primary goal was to make the Fibre
 	Channel target role work well with CTL, but many other things were
 	also fixed/improved:</p>
 
@@ -727,7 +727,7 @@
   </project>
 
   <project cat='proj'>
-    <title>Raspberry Pi: VideoCore userland application packaging</title>
+    <title>Raspberry Pi: VideoCore Userland Application Packaging</title>
 
     <contact>
       <person>
@@ -757,7 +757,7 @@
 	<tt>misc/raspberrypi-userland</tt> for them.  He also created a
 	port for <tt>omxplayer</tt> (a low-level video player that
 	utilizes VideoCore APIs) and is working on a port for Kodi
-	(ex-XBMC), a more user-firendly media player software with
+	(formerly XBMC), a more user-firendly media player software with
 	Raspberry Pi support.</p>
     </body>
   </project>
@@ -786,15 +786,15 @@
 	It is the product of the merge between the LXDE-Qt and the
 	Razor-qt projects.</p>
 
-      <p>The porting effort remains heavily a work in progress: it
-	needs some components of Plasma 5 (the new major KDE's
-	workspace).</p>
+      <p>The porting effort remains very much a work in progress: it
+	needs some components of Plasma 5, the new major KDE
+	workspace.</p>
 
       <p>Currently, only the 0.10 branch is functional.  See our
 	wiki page for a complete list of applications.</p>
 
-      <p>We also sent updates for some components of LXDE (required
-	for the LXQt desktop):</p>
+      <p>We also sent updates for some components of LXDE, required
+	for the LXQt desktop:</p>
 
       <ul>
 	<li><tt>x11/menu-cache</tt> 1.0.1</li>
@@ -851,9 +851,9 @@
 	new ports, in particular:</p>
 
       <ul>
-	<li>Socket.IO (a library for realtime web applications)</li>
+	<li>Socket.IO, a library for realtime web applications</li>
 
-	<li>Jison (a JavaSript parser generator)</li>
+	<li>Jison, a JavaSript parser generator</li>
       </ul>
 
       <p>We have improved the USES framework:</p>
@@ -865,8 +865,8 @@
 	<li><tt>node-gyp</tt> is now well-integrated into the USES
 	  framework, via the <strong>build</strong> argument.</li>
 
-	<li>The <tt>pkg-plist</tt> is now automatically generated,
-	  in order to make the <tt>portlint</tt> utility happy.</li>
+	<li>The <tt>pkg-plist</tt> is now automatically generated
+	  to make <tt>portlint</tt> happy.</li>
       </ul>
 
       <p>Each port is up-to-date.</p>
@@ -923,7 +923,7 @@
 
     <help>
       <task>
-	<p>Propose a patch to upstreamto fix Xfdashboard with our
+	<p>Propose a patch to upstream to fix Xfdashboard with our
 	  version of OpenGL (it currently coredumps).</p>
       </task>
     </help>
@@ -950,7 +950,7 @@
     <body>
       <p>I recently became involved with &os; (as in, the last 2-3
 	weeks), and found myself quickly involved with Ports development.
-	What quickly struck me was the difficulty in providing a Python
+	What struck me immediately was the difficulty in providing a Python
 	package that was depended upon by multiple versions of Python.  As
 	it turns out, poudriere can currently only generate one package
 	per port, meaning that a Python version-neutral (compatible with
@@ -959,7 +959,7 @@
 
       <p>I discussed the issue with &a.koobs;, who suggested that I
 	look into implementing a "variants protocol" within the
-	Ports framework and the necessary changes to poudriere in order to
+	Ports framework and the necessary changes to poudriere to
 	allow a port to generate more than one package.</p>
 
       <p>Support for variants is strongly needed in Ports and
@@ -994,8 +994,8 @@
 	in my heels and have implemented a proof-of-concept implementation
 	of variants in the Ports framework, including the necessary
 	modifications to poudriere in order to support it.  It was mildly
-	upsetting to find that poudriere is mostly written in Bourne shell
-	scripts, but press on I did nonetheless.</p>
+	upsettling to find that poudriere is mostly written in Bourne shell
+	scripts, but I pressed on nonetheless.</p>
 
       <p>I started with <a
 	  href="https://github.com/bapt/ports-wip/compare/variants">the
@@ -1007,7 +1007,7 @@
 	changes.</p>
 
       <p>This is a <strong>work in progress</strong>, and I would
-	love to hear your feedback.  I've enjoyed my first few weeks
+	love to hear your feedback.  I have enjoyed my first few weeks
 	working on &os;, and I hope to stay here for quite some time.</p>
     </body>
 
@@ -1025,7 +1025,7 @@
   </project>
 
   <project cat='ports'>
-    <title>New tools to enhance the porting experience</title>
+    <title>New Tools to Enhance the Porting Experience</title>
 
     <contact>
       <person>
@@ -1047,10 +1047,10 @@
     <body>
       <p>When I starting working on ports for &os; in the last
 	couple of weeks, I found that my workflow was not as efficient as
-	it could be, using just the available tools, so I made a few that
+	it could be using just the available tools, so I made a few that
 	could be useful to the development community at large.  All of
-	these have been added to the Ports tree, or otherwise will soon be
-	added, so you can play with them today!</p>
+	these have been or will soon be added to the Ports tree,
+	so you can play with them today!</p>
 
       <p><tt>pytoport</tt> is a command-line application that
 	generates a skeleton port for a given PyPI package name.  It
@@ -1073,27 +1073,27 @@
 	living in git and the larger upstream SVN tree I was using in
 	poudriere.  I built a tool called <tt>bandar</tt> that takes
 	advantage of the FUSE version of unionfs to easily overlay my dev
-	tree on the upstream tree, run linting, poudriere and generate
+	tree on the upstream tree, run linting, poudriere, and generate
 	archives with ease.</p>
 
-      <p>I'm very impressed with how easy it was to build more
+      <p>I am very impressed with how easy it was to build more
 	tooling for &os;.  I hope some of these tools will be of some use
 	to you, and as always, I'd love to hear your feedback!</p>
     </body>
 
     <help>
       <task>
-	<p>Improve skog to support searching a tree for a certain
+	<p>Improve <tt>skog</tt> to support searching a tree for a certain
 	  port.</p>
       </task>
 
       <task>
-	<p>Get the bandar port completed.</p>
+	<p>Get the <tt>bandar</tt> port completed.</p>
       </task>
 
       <task>
-	<p>Continue to improve pytoport, adding trove support and better
-	  depedency handling.</p>
+	<p>Continue to improve <tt>pytoport</tt>, adding <tt>trove</tt> support and better
+	  dependency handling.</p>
       </task>
 
       <task>
@@ -1118,14 +1118,14 @@
     <body>
       <p>The Out of Memory (OOM) code is intended to handle the
 	situation where the system needs free memory to make progress,
-	while no memory can be reused.  Most often, the situation is that
+	but no memory can be reused.  Most often, the situation is that
 	to free memory, the system needs more free memory.  Consider a
 	case where the system needs to page-out dirty pages, but needs to
 	allocate structures to track the writes.  OOM "solves"
 	the problem by killing some selection of user processes.  In other
 	words, it trades away system deadlock by suffering a partial loss
 	of user data.  The assumption is that it is better to kill a
-	process and recover data in other processes, than lose
+	process and recover data in other processes than to lose
 	everything.</p>
 
       <p>Free memory in the &os; Virtual Memory (VM) system appears
@@ -1133,16 +1133,16 @@
 	by a process, for example unmapping private anonymous regions, or
 	the last unlink of an otherwise unreferenced file with cached
 	pages.  Another source is the pagedaemon, which forcefully frees
-	pages which carry data, of course, after the data is moved to some
+	pages which carry data, of course after the data is moved to some
 	other storage, like swap or file blocks.  OOM is triggered when
 	the pagedaemon definitely cannot free memory to satisfy the
 	requests.</p>
 
-      <p>The old criteria to trigger OOM action was a combination of
-	low free swap space and a low count of free pages (the later is
+      <p>The old criteria to trigger the OOM action was a combination of
+	low free swap space and a low count of free pages (the latter is
 	expressed precisely with the paging targets constants, but this is
-	not relevant to the discussion).  That test is mostly incorrect,
-	e.g., a low free page state might be caused by a greedy consumer
+	not relevant to the discussion).  That test is mostly incorrect.
+	For example, a low free page state might be caused by a greedy consumer
 	allocating all pages freed by the page daemon in the current pass,
 	but this does not preclude the page daemon from producing more
 	pages.  Also, since page-outs are asynchronous, the previous page
@@ -1150,15 +1150,15 @@
 	they would appear some short time later.</p>
 
       <p>More seriously, low swap space does not necessarily indicate
-	that we are in trouble: lots of pages may not require swap
-	allocations to freed, e.g., clean pages or pages backed by files.
+	that we are in trouble: lots of pages might not require swap
+	allocations to be freed, like clean pages or pages backed by files.
 	The last notion is serious, since swap-less systems were
 	considered as having full swap.</p>
 
       <p>Instead of trying to deduce the deadlock from looking at
 	the current VM state, the new OOM handler tracks the history of
-	page daemon passes.  Only if several consequtive passes failed to
-	meet the paging target is an OOM kill considered neccessary.  The
+	page daemon passes.  Only when several consequtive passes failed to
+	meet the paging target is an OOM kill considered necessary.  The
 	count of consequent failed passes was selected empirically, by
 	testing on small (32M) and large (512G) machines.  Auto-tuning of
 	the counter is possible, but requires some more architectural
@@ -1169,15 +1169,15 @@
 	pages mapping entries (PTEs) installed into the machine paging
 	structures.  For different reasons, machine-dependent VM code
 	(pmap) may remove the pte for a memory-resident page.  Under some
-	circumstances, related to other measures to prevent low memory
-	deadlock, very large processes which consume all system memory,
-	could have few or no ptes, and the old OOM selector ignored the
+	circumstances related to other measures to prevent low memory
+	deadlock, very large processes which consume all system memory
+	could have few or no ptes.  The old OOM selector ignored the
 	process which caused the deadlock, killing unrelated
 	processes.</p>
 
-      <p>A new function vm_pageout_oom_pagecount() was written which
+      <p>A new function, <tt>vm_pageout_oom_pagecount()</tt>, was written which
 	applies a reasonable heuristic to estimate the number of pages
-	which would be freed by killing the given process.  This
+	freed by killing the given process.  This
 	eliminates the effect of selecting small unrelated processes for
 	OOM kill.</p>
 
@@ -1205,7 +1205,7 @@
     </links>
 
     <body>
-      <p>A new driver, <tt>cxgbei</tt>, that enables hardware
+      <p>A new driver, <tt>cxgbei</tt>, enabling hardware
 	accelerated iSCSI with Chelsio's T5- and T4-based offload-capable
 	cards, has been committed to HEAD.  Both Initiator and Target are
 	supported.  The wire traffic is standard iSCSI (SCSI over TCP as
@@ -1298,7 +1298,7 @@
     <help>
       <task>
 	<p>Test the new release on different versions of &os;, Mac
-	  OS X and Linux.  In particular, testing on Mac OS X 10.9 (Mavericks)
+	  OS X, and Linux.  In particular, testing on Mac OS X 10.9 (Mavericks)
 	  and newer would be greatly appreciated.</p>
       </task>
 
@@ -1426,7 +1426,7 @@
 
     <body>
       <p>GitLab is a web-based Git repository manager with many
-	features that is used by more than 100.000 organizations including
+	features that is used by more than 100,000 organizations including
 	NASA and Alibaba.  It also is a very long-standing entry on the
 	"Wanted Ports" list of the &os; Wiki.</p>
 
@@ -1437,9 +1437,9 @@
 	committed!</p>
 
       <p>While the new version of GitLab 8.3 eases the porting,
-	there are big changes between the last working port of GitLab
+	there are big changes since the last working port of GitLab
 	7.14.  Nonetheless, it could be expected to see the next working
-	port in the first quarter of 2016</p>
+	port in the first quarter of 2016.</p>
     </body>
 
     <sponsor>
@@ -1484,12 +1484,12 @@
 	was regularly hit by missing IPv6 support when building ports.</p>
 
       <p>I did some research into the impact of missing IPv6 support
-	on the ports tree.  The results are that 10.308 of 25.522 ports
-	are not fetchable when using IPv6.  This renders — through
-	dependencies — a total of 17.715 ports unbuildable from
-	IPv6-only systems.  All you can do than is wait and hope that
-	distcache.FreeBSD.org caches the distfile.  But this will take
-	some time, which may not be a luxury available when a piece of
+	on the ports tree.  The results are that 10,308 of 25,522 ports
+	are not fetchable when using IPv6.  This renders, through
+	dependencies, a total of 17,715 ports unbuildable from
+	IPv6-only systems.  All you can do then is wait and hope that
+	<tt>distcache.FreeBSD.org</tt> caches the distfile.  But this will take
+	some time, which might not be a luxury available when a piece of
 	software in use is hit by a security issue.</p>
 
       <p>Based on the research, a promotion campaign for IPv6 was
@@ -1528,12 +1528,12 @@
 	are being worked on in our experimental repository.</p>
 
       <p>As in previous quarters, we would like to thank several
-	people who have contributed with machines, patches and general
+	people who have contributed with machines, patches, and general
 	help.  Tobias Berner, &a.madpilot; (madpilot@), Adriaan de Groot, Ralf
 	Nolden, &a.swills; (swills@), and &a.jpaetzel; (jpaetzel@) have been
 	essential to our work.</p>
 
-      <p>The following big updates were landed in the ports tree
+      <p>The following big updates landed in the ports tree
 	this quarter.  In many cases, we have also contributed patches to
 	the upstream projects.</p>
 
@@ -1542,14 +1542,14 @@
 
 	<li>Calligra 2.9.1, the latest release of the integrated
 	  work applications suite.  Calligra had last been updated in the
-	  ports tree in the end of 2013!</li>
+	  ports tree at the end of 2013!</li>
 
 	<li>PyQt4 4.11.4, QScintilla2 2.9.1 and SIP 4.17.</li>
 
 	<li>PyQt5 5.5.1.  Thanks to the work spearheaded by Guido
 	  Falsi and Tobias Berner in the previous quarter, the PyQt5 ports
 	  have finally been committed to the ports tree.  Not only was this
-	  long-awaited on its own, but it also allows other ports to be
+	  long-awaited on its own, it allows other ports to be
 	  updated to their latest versions.</li>
 
 	<li>QtCreator 3.5.1 and 3.6.0.</li>
@@ -1562,7 +1562,7 @@
 
       <p>Work on updating the Qt5 ports to their latest version, as
 	well as porting KDE Frameworks 5 and Plasma 5 to &os;, is well
-	underway in our experimental area51 repository.  At the moment, it
+	under way in our experimental area51 repository.  At the moment, it
 	contains Qt5 5.5.1, KDE Frameworks 5.17.0, Plasma 5.5.1 and KDE
 	Applications 15.12.0.</p>
 
@@ -1580,7 +1580,7 @@
       </task>
 
       <task>
-	<p>Land the KDE Frameworks 5 and Plasma 5 ports to the
+	<p>Land the KDE Frameworks 5 and Plasma 5 ports in the
 	  tree.</p>
       </task>
 
@@ -1626,7 +1626,7 @@
     </links>
 
     <body>
-      <p>As of the end of Q4 the ports tree holds a bit more
+      <p>As of the end of the fourth quarter, the ports tree holds a bit more
 	than 25,000 ports, and the PR count is around 2,000.
 	The activity on the ports tree remains steady, with
 	about 7,000 commits performed by almost 120 active
@@ -1638,7 +1638,7 @@
 	reports were fixed, which makes an increase of about
 	20% compared to Q3.</p>
 
-      <p>In Q4 8 commit bits were taken in for safekeeping,
+      <p>In Q4, eight commit bits were taken in for safekeeping,
 	following an inactivity period of more than 18 months
 	(lioux, lippe, simon, jhay, max, sumikawa, alexey, sperber).
 	Three new developers were granted a ports commit bit (Kenji
@@ -1647,7 +1647,7 @@
 
       <p>Also related to the management of ports commit bits,
 	nox's grants were revoked, since the &os; developers
-	learnt that Juergen Lock passed away.</p>
+	learned that Juergen Lock had passed away.</p>
 
       <p>On the management side, no changes were made to the
 	portmgr team during Q4.</p>
@@ -1656,9 +1656,9 @@
 	updates or cleanups.  Amongst those noticeable changes are
 	the update to GCC 4.9, CMake to 3.4.1, PostgreSQL to 9.4, and
 	ruby-gems to 2.5.0.  Some infrastructure changes included the
-	usage of a WRKSRC different from WRKDIR when NO_WRKSUBDIR
-	is set, the removal of bsd.cpu.mk from sys.mk, and the
-	move of QT_NONSTANDARD to bsd.qt.mk.</p>
+	usage of a <tt>WRKSRC</tt> different from <tt>WRKDIR</tt> when <tt>NO_WRKSUBDIR</tt>
+	is set, the removal of <tt>bsd.cpu.mk</tt> from <tt>sys.mk</tt>, and the
+	move of <tt>QT_NONSTANDARD</tt> to <tt>bsd.qt.mk</tt>.</p>
     </body>
 
     <help>
@@ -1706,14 +1706,14 @@
     </links>
 
     <body>
-      <p>This quarter, the bugmeister team has gained a new member,
+      <p>The bugmeister team has gained a new member,
 	Mahdi Mokhtari (mokhi64 at gmail.com).  Mahdi has been contributing
 	to the &os; Project for just over one month.  After getting
 	started by creating ports for Chef-Server and MySQL 5.7 (With
 	Bernard Spil's help), an introduction to &a.koobs; led to
 	guidance on appropriate projects, such as Bugzilla development,
 	helping Bugmeister, the Bugzilla Triage team, Developers, and the
-	Community by making issue tracking better.  This is how things are
+	community by making issue tracking better.  This is how things are
 	going so far:</p>
 
       <p>Issue Tracking can be either "Defect Tracking for
@@ -1727,8 +1727,8 @@
 
       <ul>
 	<li>We have made improvements to the AutoAssigner module
-	  (not yet deployed) that was previousely developed by Marcus to
-	  assign ports' bugs to their maintainers by default, such as:
+	  (not yet deployed) that was previously developed by Marcus to
+	  assign port bugs to their maintainers by default, such as:
 
 	  <ul>
 	    <li>Improvements and bugfixes to port detection in
@@ -1743,7 +1743,7 @@
 	<li>We have developed a new module (FBSDAttachment), which
 	  automates setting maintainer-approval flag values on attachments
 	  under most conditions.  This will improve time to resolution,
-	  consistency of triage, and save manual effort on behalf of
+	  consistency of triage, and reduce manual effort by
 	  triagers and maintainers.</li>
 
 	<li>We reported and upstreamed a number of bugs in Bugzilla, working
@@ -1777,6 +1777,11 @@
       </person>
     </contact>
 
+    <links>
+      <url href="https://svnweb.freebsd.org/base?view=revision&revision=290548">Commit to Head</url>
+      <url href="https://svnweb.freebsd.org/base/head/sbin/reboot/reboot.8?r1=290548&r2=290547&pathrev=290548"><tt>reboot(8)</tt> Manual Page Changes</url>
+    </links>
+
     <body>
       <p>One of the long-missing features of &os; was the ability to
 	boot up with a temporary rootfs, configure the kernel to be able
@@ -1790,7 +1795,7 @@
 	init, and running the startup scripts as usual.</p>
 
       <p>The project is finished.  All the relevant code has been committed
-	to &os; 11-CURRENT, and is expected to ship with &os; 11.0.</p>
+	to &os; 11-CURRENT and is expected to ship with &os; 11.0.</p>
     </body>
 
     <sponsor>
@@ -1817,10 +1822,10 @@
 	aims to fill that hole by making it possible to add RCTL rules for
 	read bytes per second (BPS), write BPS, read I/O operations per
 	second (IOPS), and write IOPS.  It also adds a new throttling
-	mechanism, to delay process execution when a limit gets hit.</p>
+	mechanism to delay process execution when a limit is reached.</p>
 
       <p>The project is at the late implementation stage.  The major
-	piece of work left, apart from testing, is to integrate it with
+	piece of work left apart from testing is to integrate it with
 	ZFS.  The project is expected to ship with &os; 11.0.</p>
     </body>
 
@@ -1847,7 +1852,7 @@
     <body>
       <p>The &os; Release Engineering Team is responsible for setting
 	and publishing release schedules for official project releases
-	of &os;, announcing code freezes and maintaining the
+	of &os;, announcing code freezes, and maintaining the
 	respective branches, among other things.</p>
 
       <p>During the last quarter of 2015, the Release Engineering team
@@ -1863,7 +1868,7 @@
 
       <p>Toward the end of the year, much of the primary focus was
 	centered around the upcoming &os; 10.3 release cycle,
-	which will begin during January 2016.</p>
+	which will begin in January 2016.</p>
 
       <p>As always, help testing development snapshot builds is
 	crucial to producing quality releases, and we encourage
@@ -1895,17 +1900,17 @@
     </links>
 
     <body>
-      <p>The goal of this project is to reimplement the exisitng
+      <p>The goal of this project is to reimplement the existing
 	MMC/SD stack using the CAM framework.  This will permit utilizing
 	the well-tested CAM locking model and debug features.
-	Additionally, it will be possible to process interrupts generated
+	It will also be possible to process interrupts generated
 	by the inserted card, which is a prerequisite for implementing the
 	SDIO interface.</p>
 
       <p>The first version of the code was uploaded to
 	Phabricator for review.  The new stack is able to attach to the SD
-	card and bring it to an operational state, so it is possible to
-	read and write to/from the card.</p>
+	card and bring it to an operational state so it is possible to
+	read and write to the card.</p>
 
       <p>The only supported SD controller driver is
 	<tt>ti_sdhci</tt>, which is used on the BeagleBone Black.
@@ -1915,14 +1920,14 @@
 
     <help>
       <task>
-	<p>Rework bus/target/LUN enumeration and the locking model
-	  — I don't really understand the CAM locking and am likely to
+	<p>Rework bus/target/LUN enumeration and the locking model.
+	  I do not really understand the CAM locking and am likely to
 	  do it incorrectly.</p>
       </task>
 
       <task>
-	<p>Modify the SDHCI driver on at least one x86 platform
-	  — this will make development and collaboration easier.</p>
+	<p>Modify the SDHCI driver on at least one x86 platform.
+	  This will make development and collaboration easier.</p>
       </task>
 
       <task>
@@ -1932,7 +1937,7 @@
   </project>
 
   <project cat="proj">
-    <title>The Graphics stack on &os;</title>
+    <title>The Graphics Stack on &os;</title>
 
     <contact>
       <person>
@@ -2005,7 +2010,7 @@
 	passwords kept in memory by a browser when a kernel panic
 	occurred.  An entity that can read data from a dump device or a
 	crash directory can also extract this information from a core
-	dump.  In order to prevent this situation, the core dump should be
+	dump.  To prevent this situation, the core dump should be
 	encrypted before it is stored on the dump device.</p>
 
       <p>This project allows a kernel to encrypt a core dump during
@@ -2072,14 +2077,14 @@
 	involved with the &os; Project.  This experimental pilot project
 	has the task of setting up procedures for enhanced Issue (Problem
 	Report) management that include better
-	classification/prioritization, eventually leading to faster
-	resolution of the issues.</p>
+	classification and prioritization, eventually leading to faster
+	resolution of issues.</p>
 
       <p>We are now happy to report on the progress of this
 	experimental team:</p>
 
       <ul>
-	<li>We have set up the #FreeBSD-bugs IRC channel on
+	<li>The #FreeBSD-bugs IRC channel has been set up on
 	  Freenode and we are successfully using it to exchange information
 	  about triage processes, ask for help, propose changes and discuss
 	  related topics.</li>
@@ -2098,9 +2103,9 @@
 
 	<li>This experiment is benefiting from the introduction of
 	  newcomers to issue tracking.  It naturally resulted in a entire
-	  review of the tracking proccess from its very elementary aspects.
+	  review of the tracking process from its very elementary aspects.
 	  This "fresh eyes" participation spotted minor details
-	  along the proccess, giving the opportunity to scrutinize actual
+	  along the process, giving the opportunity to scrutinize actual
 	  procedures on a number of smaller points, followed by proposals on
 	  how to improve the overall Issue Tracking and Management.  The new
 	  ideas include both organizational and technical ideas and
@@ -2108,10 +2113,11 @@
 	  classification, the triage workflow, and Bugzilla technical
 	  improvements among others.</li>
 
-	<li>An important goal is producing documentation not only
-	  aimed at people directly engaged on issue triage tasks, but also
-	  documentation aimed at general users, about best practices for
-	  using Bugzilla and the issue management workflow.  Another
+	<li>An important goal is producing documentation about best
+	  practices for using Bugzilla and issue management workflow.
+	  This documentation should be aimed not only at people directly
+	  engaged in issue triage tasks, but also at general users.
+	  Another
 	  relevant point is that feedback from triage team can be used to
 	  improve Bugzilla in terms of adjusting existing features to best
 	  fit &os;'s needs, and development of new features (please see
@@ -2126,7 +2132,7 @@
 	  report.</li> </ul>
 
       <p>Since the Issue Triage Team is very young, we expect more
-	information be available and more actions be reported upon in the
+	information be available and more actions be reported in the
 	next Status report.</p>
     </body>
 
@@ -2152,7 +2158,7 @@
   </project>
 
   <project cat='misc'>
-    <title>relaunchd</title>
+    <title><tt>relaunchd</tt></title>
 
     <contact>
       <person>
@@ -2201,7 +2207,7 @@
 
       <task>
 	<p>Add support for monitoring files and directories for
-	  changes, and launching jobs when changes are detected.</p>
+	  changes and launching jobs when changes are detected.</p>
       </task>
 
       <task>
@@ -2210,14 +2216,14 @@
       </task>
 
       <task>
-	<p>Improve the documentation and providing more examples of
-	  how to use it.</p>
+	<p>Improve the documentation and provide more examples of
+	  usage.</p>
       </task>
     </help>
   </project>
 
   <project cat='kern'>
-    <title>&os; Integration Services (BIS) </title>
+    <title>&os; Integration Services (BIS)</title>
 
     <contact>
       <person>
@@ -2243,21 +2249,22 @@
     </links>
 
     <body>
-      <p>When &os; virtual machines (VMs) run on Hyper-V,  in order
+      <p>When &os; virtual machines (VMs) run on Hyper-V, using
+	Hyper-V synthetic devices is recommended
 	to get the best network and storage performance and make full use
-	of all the benefits that Hyper-V provides, it is recommended to
-	use Hyper-V synthetic devices.  The collection of drivers that are
+	of all the benefits that Hyper-V provides.
+	The collection of drivers that are
 	required to run Hyper-V synthetic devices in &os; are known as
 	&os; Integration Services (BIS).  Some of the BIS drivers (like
 	network and storage drivers) have existed in &os; 9.x and 10.x for
 	years, but there are still some performance and stability issues
-	and bugs.  Additionally, compared with Windows and Linux VMs, the
-	current BIS lacks some important features, such as the virtual
+	and bugs.  Compared with Windows and Linux VMs, the
+	current BIS lacks some important features, such as virtual
 	Receive Side Scaling (vRSS) support in the Hyper-V network driver
-	and the support for UEFI VM (boot from UEFI), among others.</p>
+	and support for UEFI VM (boot from UEFI), among others.</p>
 
       <p>We are now working more on the issues and performance
-	tuning to make &os; VM run better on Hyper-V and the Hyper-V based
+	tuning to make &os; VMs run better on Hyper-V and the Hyper-V based
 	cloud platform Azure.</p>
 
       <p>Our work during 2015Q4 is documented below:</p>
@@ -2301,7 +2308,7 @@
 
 	    <li>Added ioctl support for SIOCGIFMEDIA for the Hyper-V
 	      network driver, fixing PR 187006 ([Hyper-V] dynamic
-	      address (DHCP) obtaining doesn't work on HYPER-V OS
+	      address (DHCP) obtaining does not work on HYPER-V OS
 	      2012 R2).</li>
 
 	    <li>Sent out patches to add an interrupt counter for
@@ -2322,18 +2329,18 @@
 	  </ul>
 	</li>
 
-	<li>We plan to add support for UEFI VMs (a.k.a., Hyper-V
+	<li>We plan to add support for UEFI VMs (Hyper-V
 	  Generation-2 VMs).  Currently some issues and to-do items were
-	  identified: e.g., we cannot use the i8254 PIT to calibrate the
+	  identified.  For example, we cannot use the i8254 PIT to calibrate the
 	  TSC because the i8254 PIT does not exist in a UEFI VM, and we
 	  need to add support for the Hyper-V synthetic
 	  keyboard/mouse/framebuffer device.</li>
 
 	<li>We are working on a disk detection issue: when a &os; VM
 	  runs on a Windows Server 2016 Technical Preview host, the VM
-	  will detect 16 disks whereas only 1 disk is configured for the
-	  VM.  Due to this issue, VMs running on these hosts can fail to
-	  boot.  A workaround patch was made and we are trying to make a
+	  will detect 16 disks when only one disk is configured for the
+	  VM.  VMs running on these hosts can fail to
+	  boot.  A workaround patch was created and we are trying to make a
 	  formal fix.</li>
 
 	<li>We are tidying up some internal BIS test cases and plan
@@ -2347,7 +2354,7 @@
   </project>
 
   <project cat='proj'>
-    <title>Mellanox iSCSI Extensions For RDMA (iSER) Support</title>
+    <title>Mellanox iSCSI Extensions for RDMA (iSER) Support</title>
 
     <contact>
       <person>
@@ -2404,7 +2411,7 @@
   </project>
 
   <project cat='arch'>
-    <title>Improvements for ARMv6/v7 support</title>
+    <title>Improvements for ARMv6/v7 Support</title>
 
     <contact>
       <person>
@@ -2677,15 +2684,15 @@
 	scalability and the ability to add advanced features to the
 	routing stack.</p>
 
-      <p>Currently, the packet output path suffers from excessive
-	locking, acquiring and releasing 4 distinct contested locks is
-	required in order to convert a packet to a frame suitable to put
+      <p>The current packet output path suffers from excessive
+	locking.  Acquiring and releasing four distinct contested locks is
+	required to convert a packet to a frame suitable to put
 	on the wire.  The first project goal is to reduce the number of
 	locks needed to just two <tt>rmlock(9)</tt>s for the output path,
 	which permits close-to-linear scaling.</p>
 
       <p>Since September, one of the locks (used to protect
-	link-level entries) is completely eliminated from the packet data
+	link-level entries) has been completely eliminated from the packet data
 	path.  A new routing API was introduced, featuring better
 	scalability and hiding routing internals.  Most of the consumers
 	of the old routing API were converted to use the new API.</p>
@@ -2714,13 +2721,13 @@
 
     <body>
       <p>&a.bdrewery; (bdrewery@) has been working to improve the
-	build framework as well as buildworld build times.  The build
-	system has largely been untouched by large-scale changes for many
+	build framework as well as <tt>buildworld</tt> build times.  The build
+	system has been largely untouched by large-scale changes for many
 	years.  Most of the effort has been on improving the recent
 	<tt>META_MODE</tt> merge that was presented at BSDCan 2014.  This
 	is a new build system that is not currently enabled by default but
 	brings many benefits.  Beyond that, some highlights of the work
-	changing buildworld are:</p>
+	changing <tt>buildworld</tt> are:</p>
 
       <ul>
 	<li><tt>WITH_FAST_DEPEND</tt>, which avoids calling
@@ -2729,15 +2736,15 @@
 	  scheme was pre-processing all source files twice.  The new version
 	  saves 16-35% in build times.</li>
 
-	<li><tt>WITH_CCACHE_BUILD</tt> adds built-in ccache support,
+	<li><tt>WITH_CCACHE_BUILD</tt> adds built-in <tt>ccache</tt> support,
 	  avoiding many of the historical pitfalls of changing <tt>CC</tt>
-	  in <tt>make.conf</tt> to use ccache.</li>
+	  in <tt>make.conf</tt> to use <tt>ccache</tt>.</li>
 
 	<li>Many improvements for parallelization of the build.</li>
 
 	<li><tt>LIBADD</tt> improvements to ensure proper usage of
 	  this tool to replace duplicate <tt>LDADD</tt> and <tt>DPADD</tt>
-	  statements.  Further work is underway to reduce overlinking.</li>
+	  statements.  Further work is under way to reduce overlinking.</li>
 
 	<li>A lot of cleanup of improper framework usage.</li>
 
@@ -2760,7 +2767,7 @@
   </project>
 
   <project cat='bin'>
-    <title>ELF Tool Chain tools</title>
+    <title>ELF Tool Chain Tools</title>
 
     <contact>
       <person>

*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***


More information about the svn-doc-all mailing list