diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml b/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml
index dc819a3fd6..116d6ed96f 100644
--- a/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml
+++ b/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml
@@ -97,8 +97,8 @@
 
       <p>The &os; Release Engineering Team completed the 10.3-RELEASE
 	cycle late April, led by &a.marius;.  The release was one week
-	behind the original schedule, to accommodate for a few last
-	minute critical issues that were essential to include in the
+	behind the original schedule, to accommodate for a few
+	last-minute critical issues that were essential to include in the
 	final release.</p>
 
       <p>The &os;&nbsp;11.0-RELEASE cycle started late May, one month
@@ -106,10 +106,10 @@
 	to accommodate for packaging the &os; base system with the
 	<tt>pkg(8)</tt> utility.  However, as work on this progressed,
 	it became apparent that there were too many outstanding
-	issues.  As a result, packaged base will be a "beta" feature
+	issues.  As a result, packaged base will be a &quot;beta&quot; feature
 	for 11.0-RELEASE, with the goal of promoting it to a
-	first-class feature in 11.1-RELEASE, with additional
-	provisions to ensure a seamless transition for earlier
+	first-class feature in 11.1-RELEASE.  It is expected that
+	provisions will be made to ensure a seamless transition from older
 	supported releases.</p>
 
       <p>Despite the fact that packaged base is not going to be a
@@ -120,7 +120,7 @@
     </body>
 
     <sponsor>
-	The &os; Foundation
+      The &os; Foundation
     </sponsor>
   </project>
 
@@ -144,10 +144,10 @@
 	come to switch to 4.2.</p>
 
       <p>While there is ongoing progress to remove Rails 3.2 from
-	the ports tree, there are some major updates blocking this
-	process.  The most recent blocker was the outstanding update
-	of <tt>www/redmine</tt> from 2.6 to 3.2. This has completed
-	successfully, so we can now move on.</p>
+	the ports tree, there are some ports for which this is a major
+	update that block the overall process.  The most recent blocker
+	was the outstanding update of <tt>www/redmine</tt> from 2.6 to
+	3.2. This has completed successfully, so we can now move on.</p>
 
       <p>To help with porting or testing, feel free to contact me or
 	the <tt>ruby@FreeBSD.org</tt> mailing list.</p>
@@ -180,26 +180,26 @@
 
     <body>
       <p>Allwinner SoCs are used in multiple hobbyist devboards and
-	single board computers.  Recently, support for these SoCs
+	single-board computers.  Recently, support for these SoCs
 	received many updates.</p>
 
       <p>Theses tasks were completed during the second quarter of
 	2016:</p>
 
       <ul>
-	<li>Switch to upstream DTS is complete</li>
+	<li>Switch to upstream DTS</li>
 
 	<li>A83T SoC support</li>
 
 	<li>H3 SoC support</li>
 
-	<li>Switch to new clock framework</li>
+	<li>Switch to the new clock framework</li>
 
-	<li>Convert A10 interrupt controller to INTRNG</li>
+	<li>Convert the A10 interrupt controller to <tt>INTRNG</tt></li>
 
 	<li>OHCI support</li>
 
-	<li>Generic ALLWINNER kernel config file</li>
+	<li>A generic <tt>ALLWINNER</tt> kernel config file</li>
 
 	<li>A20/A31 NMI support</li>
 
@@ -213,8 +213,8 @@
 
 	<li>A83T Security ID support</li>
 
-	<li>Allwinner Gigabit Ethernet controller found in
-	  H3/A83T/A64</li>
+	<li>Support for the Allwinner Gigabit Ethernet controller found
+	  in H3/A83T/A64</li>
 
 	<li>USB OTG
 	  <a href="https://reviews.freebsd.org/D5881">(in review)</a></li>
@@ -267,10 +267,10 @@
     </contact>
 
     <body>
-      <p>Now that the process-shared locks are implemented for our
-	POSIX threads implementation library, <tt>libthr</tt>,
-	the only major lacking feature for POSIX compliance is robust
-	mutexes.  Robust mutexes allow the application to detect, and
+      <p>Now that process-shared locks are implemented for our
+	POSIX threads implementation, <tt>libthr</tt>,
+	the only major feature lacking for POSIX compliance is robust
+	mutexes.  Robust mutexes allow applications to detect, and
 	theoretically, recover from crashes which occur while
 	modifying the shared state.  The supported model is to protect
 	shared state by a <tt>pthread_mutex</tt>, and the crash is
@@ -284,7 +284,7 @@
 	recover from failures.  The <tt>pthread_mutex_lock()</tt>
 	function may return new error <tt>EOWNERDEAD</tt>, which
 	indicates that the previous owner of the lock terminated while
-	still owning the lock.  Despite returning the non-zero value,
+	still owning the lock.  Despite returning this non-zero value,
 	the lock is granted to the caller.  In the simplest form, an
 	application may detect the error and refuse to operate until
 	the persistent shared data is recovered, such as by manual
@@ -299,22 +299,22 @@
 
       <p>It is curious but not unexpected that this interface is not
 	used widely.  The only real-life application which utilizes it
-	is Samba.  Using Samba with an updated FreeBSD base uncovered
-	minor bugs both in the FreeBSD robustness implementation, and
+	is Samba.  Using Samba with an updated &os; base uncovered
+	minor bugs both in the &os; robust mutex implementation, and
 	in Samba itself.</p>
 
-      <p>It is believed that <tt>libthr</tt> in FreeBSD 11 is
-	POSIX-compliant for large features.  Further work is planned
-	to look at the lock structures inlining to remove overhead
-	and improve performance of the library.</p>
+      <p>It is believed that <tt>libthr</tt> in &os; 11 is
+	POSIX-compliant for major features.  Further work is planned
+	to look at inlining the lock structures to remove overhead
+	and improve the performance of the library.</p>
 
       <p>Most of the implementation of the robustness feature
 	consisted of making small changes in the lock and unlock
 	paths, both in <tt>libthr</tt> and in <tt>kern_umtx.c</tt>.
 	This literally required reading all of the code dealing with
-	mutexes and conditional variables, which was something I
+	mutexes and condition variables, which was something I
 	wanted to help future developers with.  In the end, with the
-	help of Ed Maste, the man pages for <tt>umtx(2)</tt> and all
+	help of Ed Maste, man pages for <tt>umtx(2)</tt> and all
 	<tt>thr*(2)</tt> syscalls were written and added to the base
 	system's documentation set.
       </p>
@@ -329,7 +329,7 @@
   </project>
 
   <project cat='proj'>
-    <title>EFI Refactoring, GELI Support</title>
+    <title>EFI Refactoring and GELI Support</title>
 
     <contact>
       <person>
@@ -357,16 +357,17 @@
 	too much effort.</p>
 
       <p>Both <tt>boot1</tt> and <tt>loader</tt> have been refactored
-	to talk through the <tt>EFI_SIMPLE_FILE_SYSTEM</tt> interface.
-	In <tt>loader</tt>, this is accomplished with a dummy
+	to utilize the <tt>EFI_SIMPLE_FILE_SYSTEM</tt> interface.
+	In the loader, this is accomplished with a dummy
 	filesystem driver that is just a translation layer between the
-	<tt>loader</tt> filesystem interface and
+	loader filesystem interface and
 	<tt>EFI_SIMPLE_FILE_SYSTEM</tt>.  A reverse translation layer
 	allows the existing filesystem drivers to function as EFI
 	drivers.</p>
 
-      <p>The EFI refactoring by itself exists in
-	<a href="https://github.com/emc2/freebsd/tree/efize">this branch</a>.</p>
+      <p>The EFI refactoring by itself exists in a
+	<a href="https://github.com/emc2/freebsd/tree/efize">branch
+	  on github</a>.</p>
 
       <p>Additionally, GELI support has been added using the EFI
 	refactoring.  This allows booting from a GELI-encrypted
@@ -376,7 +377,7 @@
 	framework, which allows injection of keys directly into a
 	loaded kernel, without the need to pass them through
 	arguments or environment variables.  This patch only uses the
-	intake buffer for EFI GELI support as legacy BIOS GELI support
+	intake buffer for EFI GELI support, as legacy BIOS GELI support
 	still uses environment variables.</p>
 
       <p>EFI GELI support depends on the
@@ -404,7 +405,7 @@
 	</li>
 
 	<li>
-	  <p>Install an EFI shell on the ESP.</p>
+	  <p>Install an EFI shell on the EFI System Partition (ESP).</p>
 	</li>
 
 	<li>
@@ -439,7 +440,7 @@
 
 	<li>
 	  <p>Try switching over to an encrypted main partition once
-	    everything else has worked.</p>
+	    everything else is working.</p>
 	</li>
       </ol>
     </body>
@@ -447,9 +448,8 @@
     <help>
       <task>Testing is needed.</task>
 
-      <task>Code will need review and some <tt>style(9)</tt>
-	normalization must occur before this code goes into
-	FreeBSD.</task>
+      <task>The code will need review, and some <tt>style(9)</tt>
+	normalization must occur before it goes into &os;.</task>
     </help>
   </project>
 
@@ -475,7 +475,7 @@
     </contact>
 
     <body>
-      <p>The port has been updated to GDB 7.11.1.</p>
+      <p>The <tt>devel/gdb</tt> port has been updated to GDB 7.11.1.</p>
 
       <p>Support for system call catchpoints has been committed
 	upstream.  Support for examining ELF auxiliary vector data via
@@ -484,12 +484,12 @@
     </body>
 
     <help>
-      <task>Figure out why the <tt>powerpc kgdb</tt> targets are not
+      <task>Figure out why the <tt>powerpc</tt> <tt>kgdb</tt> targets are not
 	able to unwind the stack past the initial frame.</task>
 
       <task>Add support for more platforms, such as <tt>arm</tt>,
-	<tt>mips</tt>, and <tt>aarch64</tt>, to upstream gdb for both
-	userland and kgdb.</task>
+	<tt>mips</tt>, and <tt>aarch64</tt>, to upstream <tt>gdb</tt> for both
+	userland and <tt>kgdb</tt>.</task>
 
       <task>Add support for debugging <tt>powerpc</tt> vector
 	registers.</task>
@@ -516,11 +516,11 @@
     </contact>
 
     <links>
-       <url href="https://svnweb.freebsd.org/base/projects/vnet/">Projects workspace (all merged to head now).</url>
+       <url href="https://svnweb.freebsd.org/base/projects/vnet/">Project workspace (all merged to head now).</url>
     </links>
 
     <body>
-      <p>VIMAGE is a virtualization framework on top of FreeBSD jails
+      <p>VIMAGE is a virtualization framework on top of &os; jails
 	that was introduced to the kernel about eight years ago with
 	the <tt>vnet</tt> virtualized network stack.</p>
 
@@ -533,8 +533,9 @@
       <p>The <tt>vnet</tt> teardown has been changed to be from top to
 	bottom, trying to tear down layer by layer.  This is
 	preferable to removing interfaces first and then cleaning
-	everything up, as no more packets could flow.  Along with this
-	work, various parts with potential memory leaks were plugged.
+	everything up, as no more packets could flow once the
+	interfaces are gone.  Along with this
+	work, various paths with potential memory leaks were plugged.
 	Lastly, <tt>vnet</tt> support was added to formerly
 	unvirtualized components, such as the <tt>pf</tt> and
 	<tt>ipfilter</tt> firewalls and some virtual interfaces.</p>
@@ -543,7 +544,7 @@
     <sponsor>The FreeBSD Foundation</sponsor>
 
     <help>
-      <task>Please test FreeBSD 11.0-ALPHA6 or later.  When reporting
+      <task>Please test &os; 11.0-ALPHA6 or later.  When reporting
 	a problem, use the <tt>vimage</tt> keyword in the FreeBSD bug
 	tracker.</task>
     </help>
@@ -569,9 +570,9 @@
     <body>
       <p>Half a year ago, I started a promotion campaign to improve
 	support for fetching ports via IPv6.  Research performed in
-	December, 2015 showed that 10,308 of 25,522 ports are not
-	fetchable when using IPv6-only as these ports ignore the <a
-	  href="distcache.freebsd.org">FreeBSD.org pkg mirror</a>.</p>
+	December 2015 showed that 10,308 of 25,522 ports were not
+	fetchable when using IPv6-only, as these ports ignore the <a
+	  href="distcache.freebsd.org">FreeBSD.org <tt>pkg</tt> mirror</a>.</p>
 
       <p>As a result of the campaign, the following servers now
 	successfully support IPv6:</p>
@@ -590,7 +591,7 @@
 
       <p>This enables 711 more ports to be fetched via IPv6.</p>
 
-      <p>I would like to thank Wolfgang Zenker who is very active in
+      <p>I would like to thank Wolfgang Zenker, who is very active in
 	supporting the adoption of IPv6.  During the latest RIPE
 	meeting, he brought up the topic of non-support of IPv6
 	being a hindrance to business.  I am hopeful that his talk
@@ -637,15 +638,15 @@
     </contact>
 
     <links>
-      <url href="https://wiki.freebsd.org/HyperV">FreeBSD Virtual Machines on Microsoft Hyper-V</url>
-      <url href="https://technet.microsoft.com/en-us/library/dn531030.aspx">Supported Linux and FreeBSD virtual machines for Hyper-V on Windows</url>
+      <url href="https://wiki.freebsd.org/HyperV">&os; Virtual Machines on Microsoft Hyper-V</url>
+      <url href="https://technet.microsoft.com/en-us/library/dn531030.aspx">Supported Linux and &os; virtual machines for Hyper-V on Windows</url>
     </links>
 
     <body>
       <p>During BSDCan 2016, Microsoft <a
 	  href="https://azure.microsoft.com/en-us/blog/freebsd-now-available-in-azure-marketplace/">announced</a>
-	the global availability of FreeBSD 10.3 images in Azure.
-	There are many FreeBSD-based Azure virtual appliances in the
+	the global availability of &os; 10.3 images in Azure.
+	There are many &os;-based Azure virtual appliances in the
 	Azure Marketplace, including Citrix Systems' NetScaler and
 	Netgate's pfSense.  Microsoft also made an in-depth technical
 	presentation to introduce how the performance of the Hyper-V
@@ -659,11 +660,11 @@
 	performance of Hyper-V network and storage device drivers.
 	Work is ongoing to replace the internal data structure in the
 	LRO kernel API from a singly-linked list to a double-linked
-	list, to speed up the LRO lookup by hash table, and to compare
+	list, to speed up the LRO lookup by hash table, and to evaluate
 	the performance with <tt>tcp_lro_queue_mbuf()</tt>.</p>
 
       <p>The handling of SCSI inquiry in the Hyper-V storage driver is
-	enhanced to make sure disk hotplug and <tt>smartctl(8)</tt>
+	enhanced to make sure that disk hotplug and <tt>smartctl(8)</tt>
 	work reliably.  Refer to <a
 	  href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210425">PR 210425</a>
 	and <a
@@ -698,12 +699,12 @@
       <url href="http://ceph.com">Ceph main site</url>
       <url href="https://github.com/ceph/ceph">Main repository</url>
       <url href="https://github.com/wjwithagen/ceph">My Fork </url>
-      <url href="https://github.com/ceph/ceph/pull/7573">The git PULL with all changes</url>
+      <url href="https://github.com/ceph/ceph/pull/7573">Pull request with &os;-specific changes to Ceph</url>
     </links>
 
     <body>
-      <p>Ceph is a distributed object store and file system designed
-	to provide  excellent performance, reliability, and
+      <p>Ceph is a distributed object store and filesystem designed
+	to provide excellent performance, reliability, and
 	scalability.  It provides the following features:</p>
 
       <ol>
@@ -716,38 +717,38 @@
 	  access to block device images that are striped and
 	  replicated across the entire storage cluster.</li>
 
-	<li>File System: Ceph provides a POSIX-compliant network file
-	  system that aims for high performance, large data storage,
+	<li>File System: Ceph provides a POSIX-compliant network
+	  filesystem that aims for high performance, large data storage,
 	  and maximum compatibility with legacy applications.</li>
       </ol>
 
-      <p>I started looking into Ceph as using HAST with CARP and
+      <p>I started looking into Ceph because using HAST with CARP and
 	<tt>ggate</tt> did not meet my requirements.  My primary goal
 	with Ceph is to run a storage cluster of ZFS storage nodes
-	where the clients run bhyve on RBD disks stored in Ceph.</p>
+	where the clients run <tt>bhyve</tt> on RBD disks stored in Ceph.</p>
 
       <p>The &os; build process can build most of the tools in
-	Ceph.  However, the RBD-dependent items do not work since
+	Ceph.  However, the RBD-dependent items do not work, since
 	&os; does not yet provide RBD support.</p>
 
       <p>Since the last quarterly report, the following progress was
 	made:</p>
 
       <ol>
-	<li>The changeover from using CMake to Automake results in a
+	<li>Switching to using CMake from Automake results in a
 	  much cleaner development environment and better test output.
 	  The changes can be found in the
 	  <tt>wip-wjw-freebsd-cmake</tt> branch.</li>
 
-	<li>Throttling code has been overhauled to prevent live locks.
+	<li>The throttling code has been overhauled to prevent live locks.
 	  These mainly occur on &os; but also manifest on Linux.</li>
 
-	<li>Fixed a few more tests.  On one occasion, I was able to
-	  complete the full test set without errors.</li>
+	  <li>A few more tests were fixed.  On one occasion, I was able to
+	  complete the full test suite without errors.</li>
       </ol>
 
       <p>11-CURRENT is used to compile and build test Ceph.  The
-	Clang toolset needs to be at least version 3.7 as Clang 3.4
+	Clang toolset needs to be at least version 3.7, as Clang 3.4
 	does not have all of the capabilities required to compile
 	everything.</p>
 
@@ -755,7 +756,7 @@
 
       <ul>
 	<li>
-	  <p>Install <tt>bash</tt> and link it in <tt>/bin</tt>
+	  <p>Install <tt>bash</tt> and link to it in <tt>/bin</tt>
 	    (requires root privileges):</p>
 
 	  <p><tt>sudo pkg install bash</tt></p>
@@ -787,33 +788,33 @@
 
       <ul>
 	<li>RBD: Rados Block Devices are currently implemented in the
-	  Linux kernel but there used to be a userspace
+	  Linux kernel, but there used to be a userspace
 	  implementation.  It is possible that <tt>ggated</tt> could
-	  be used as a template since it provides some of the same
+	  be used as a template, since it provides some of the same
 	  functionality and it has a userspace counterpart.</li>
 
 	<li>BlueStore: &os; and Linux have a different AIO API which
-	  needs to be made compatible.  There has been some
+	  needs to be bridged.  There has been some
 	  discussion about <tt>aio_cancel</tt> not working for all
 	  device types in &os;.</li>
 
-	<li>CephFS: Cython tries to access an internal field in dirent
-	  which does not compile.</li>
+	<li>CephFS: Cython tries to access an internal field in
+	  <tt> struct dirent</tt>, which fails to compile.</li>
 
-	<li>Tests that verify the correct working of the above are
-	  also excluded from the testset.</li>
+	<li>Tests that verify the correct functionality of these are
+	  also excluded from the test suite.</li>
       </ul>
 
       <p>Tests Not Yet Included:</p>
 
       <ul>
 	<li><tt>ceph-detect-init/run-tox.sh</tt>: the current
-	  implementation does not know anything about &os;
-	  <tt>rc-init</tt>.</li>
+	  implementation does not know anything about &os;'s
+	  <tt>rc</tt> system.</li>
 
-	<li>Tests that make use of <tt>nosestests</tt> do not really
-	  work since <tt>nostests</tt> is not in <tt>/usr/bin</tt>,
-	  and calling <tt>/usr/bin/env/nosetests</tt> does not work on
+	<li>Tests that make use of <tt>nosetests</tt> do not really
+	  work since <tt>nosetests</tt> is not in <tt>/usr/bin</tt>,
+	  and calling <tt>/usr/bin/env nosetests</tt> does not work on
 	  &os;.</li>
 
 	<li><tt>test/pybind/test_ceph_argparse.py</tt></li>
@@ -823,13 +824,13 @@
     </body>
 
     <help>
-      <task>The current and foremost task it to get the test set to
+      <task>The current and foremost task it to get the test suite to
 	complete without errors.</task>
 
       <task>Build an automated test platform that will build
 	<tt>ceph/master</tt> on &os; and report the results back to
 	the Ceph developers.  This will increase the maintainability
-	of the &os; side of things as developers are signaled that
+	of the &os; side of things, as developers are signaled that
 	they are using Linux-isms that will not compile or run on
 	&os;.  Ceph has several projects that support this: Jenkins,
 	teuthology, and palpito.  But even a
@@ -845,7 +846,7 @@
 	Device).</task>
 
       <task>Investigate if an in-kernel RBD device could be developed
-	ala <tt>ggate</tt>.</task>
+	akin to <tt>ggate</tt>.</task>
 
       <task>Investigate the keystore which currently prevents the
 	building of Cephfs and some other parts.</task>
@@ -890,7 +891,7 @@
 	&os;, which is quite a commendation.</p>
 
       <p>Current work aims to fix the open problems, get the latest
-	major version into the port, and create the documentation for
+	major version into the port, and create documentation for
 	the update progress.</p>
     </body>
   </project>
@@ -931,107 +932,117 @@
       <p><tt>proccontrol -m (trace|aslr) [-q] [-s (enable|disable)]
 	[-p pid | command]</tt></p>
 
-      <p><tt>-m</tt> (specifies trace mode to control debugger
+      <p>with possible arguments</p>
+
+      <p><tt>-m</tt> (specifies the trace mode to control debugger
 	attachments)</p>
 
       <p><tt>-q</tt> (queries the state of the specified mode for the
-	process with the PID specified by <tt>-p</tt> option)</p>
+	process with the PID specified by the <tt>-p</tt> option)</p>
 
       <p><tt>-e</tt> (toggles the feature on or off for the given
 	process or itself)</p>
 
-      <p>If the command is specified, it inherits the applied
+      <p>If a command is specified, it inherits the applied
 	settings from <tt>proccontrol</tt>.  For instance, to start a
 	build of a program with ASLR disabled, use
 	<tt>proccontrol -m aslr -s disable make</tt>.</p>
 
-      <p>The ports exp run was done with ASLR tuned up to the most
+      <p>A ports exp-run was done with ASLR tuned up to the most
 	aggressive settings.  The results can be found in <a
 	  href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208580">PR 208580</a>.</p>
 
+      <p>Case study: Lisp</p>
+
       <p>SBCL is an interesting case which illustrates several points.
 	It is much smaller than JDK, and its build system is easier to
-	work with.  The code provides a very non C-ish language
-	runtime which utilizes a lot of corner cases and non-standard
-	uses of VM, at least from the point of view of a typical C
+	work with.  The code provides a very non C-like language
+	runtime which utilizes a lot of corner cases and makes non-standard
+	uses of the VM system, at least from the point of view of a typical C
 	programmer.</p>
 
       <p>SBCL compiles Lisp forms into the machine native code and
 	manages its own arena for objects.  The precompiled Lisp
-	runtime is mapped from the <tt>core</tt> file.  SBCL relies on
+	runtime is mapped from a <tt>core</tt> file.  SBCL relies on
 	the operating system's C runtime for the initial load of Lisp,
 	and needs a functional <tt>libc</tt> to issue many system
 	calls, including syscalls, as well as the dynamic loader.  The
 	end result is that there are unfixed <tt>mmap(2)</tt> calls
-	during both startup and runtime, interfering with the
-	<tt>MAP_FIXED mmaps</tt>.  The core file loading and arenas
-	are hard-coded to exist at fixed addresses.</p>
+	during both startup and runtime, interfering with other
+	<tt>MAP_FIXED mmaps</tt>.  The loading of the core file
+	and the private arenas are hard-coded to exist at fixed
+	addresses.</p>
 
       <p>This happens to work on the default address map, which is not
 	changed often, so the SBCL choices of the base addresses
 	evolved to work.  But any significant distortion of the
 	standard map results in <tt>SBCL mmap(MAP_FIXED)</tt> requests
-	to override memory from other allocators.</p>
+	attempting to override memory from other allocators.</p>
 
       <p>&os; uses the <tt>MAP_EXCL</tt> flag to <tt>mmap(2)</tt>,
-	which must be used in <tt>MAP_FIXED|MAP_EXCL</tt> form to
-	cause <tt>mmap(2)</tt> failure if the requested range is
+	which must be used in the <tt>MAP_FIXED|MAP_EXCL</tt> form to
+	cause <tt>mmap(2)</tt> to fail if the requested range is
 	already used.  I tried to force <tt>MAP_FIXED</tt> requests
-	from SBCL to implicitely set <tt>MAP_EXCL</tt>, but this did
+	from SBCL to implicitly set <tt>MAP_EXCL</tt>, but this did
 	not go well since SBCL sometimes pre-allocates regions for
 	later use with <tt>MAP_FIXED</tt>.  So, <tt>MAP_EXCL</tt>
 	mappings failed, dumping the process into <tt>ldb</tt>.</p>
 
-      <p>On Linux, if a kernel is detected in AS-randomization mode,
-	the initial SBCL runtime sets personality to non-random and
+      <p>On Linux, if it is detected that the kernel is in AS-randomization mode,
+	the initial SBCL runtime sets its personality to non-random and
 	re-execs.  This might be a solution for &os; as well, after
 	the ASLR patch is committed, so that the <tt>procctl(2)</tt>
 	knob is officially available.</p>
 
       <p>SBCL still has issues on Linux, even with re-exec, when
-	more aggressive randomization from PaX patch is applied, as
+	more aggressive randomization from the PaX patch is applied, as
 	seen in <a
 	  href="https://bugs.launchpad.net/sbcl/+bug/1523213">bug
 	  1523213</a>.</p>
 
+      <p>Case study: Emacs</p>
+
       <p>The Emacs build procedure involves loading the
 	<tt>temacs</tt> image with the compiled Emacs Lisp files and
-	then dumping the memory to recreate the image with the
-	preloaded content, in order to shrink the start time.</p>
+	then dumping its memory to create an image with the content
+	preloaded, in order to reduce startup time.</p>
 
       <p>Recent Emacs sources seem to generally avoid
 	<tt>MAP_FIXED</tt>, except in some situations.  When Emacs
 	does use the flag, it carefully checks that the selected
-	region is not busy.  In fact, Emacs would benefit from
+	region is not busy.  In fact, Emacs would benefit from using
 	<tt>MAP_EXCL</tt>.</p>
 
       <p>I tried several runs of building Emacs and running the dumped
-	binary, but was not able to reproduce the issue.  It seems
+	binary, but was not able to reproduce any issues.  It seems
 	that the code improved enough to tolerate ASLR both in Linux
 	and NetBSD without turning it off.</p>
 
       <p>In my opinion, it is not reasonable to fight the issues in
 	the kernel as most of it is not fixable from the kernel side.
 	The <tt>procctl(2)</tt> interface and <tt>proccontrol(1)</tt>
-	utilities provide the override when needed, but are not
+	utilities provide an override when needed, but are not
 	automated.</p>
 
+      <p>Conclusions</p>
+
       <p>The set of ports which cannot be built with ASLR turned on
 	should be limited but fluid.  However, exp-runs may not
 	reliably uncover all problems due to randomization, as seen in
-	the Emacs example.  In the route to enable ASLR by default in
-	non-aggressive settings, the ports framework should provide an
+	the Emacs example.  In the route to enable ASLR by default (with
+	non-aggressive settings), the ports framework should provide an
 	option like <tt>ASLR_UNSAFE=yes</tt> which spawns
 	<tt>proccontrol -m aslr -s disable make</tt> for the build
 	stages of the unsafe port.  Users would still need to be aware
 	of <tt>proccontrol(1)</tt> in order to run the resulting
-	binary.</p>
+	binary or wrapper scripts provided to do so.</p>
 
       <p>A recommended approach is a flag in the ELF binary to mark
 	it as not compatible with non-standard AS layouts.  This frees
 	users from having to use <tt>proccontrol(1)</tt>, but still
-	requires patching and upstreaming.  This approach is also
-	useful outside the context of ASLR.  However, the
+	requires patching the application's build process and
+	upstreaming the changes.  This approach is also
+	useful outside the context of ASLR.  However, that
 	mechanism is not yet ready, and developing it is a larger work
 	than ASLR itself.</p>
     </body>
@@ -1062,7 +1073,7 @@
       <url href="http://wiki.FreeBSD.org/Graphics">Graphics Stack Roadmap and Supported Hardware Matrix</url>
       <url href="https://github.com/FreeBSD/freebsd-ports-graphics">Ports Development Repository</url>
       <url href="https://github.com/FreeBSDDesktop/freebsd-base-graphics/tree/drm-next-4.6">DRM 4.6 Development Repository</url>
-      <url href="https://wiki.freebsd.org/SummerOfCodeIdeas#Devices_management:_link_.2Fdev_entries_to_sysctl_nodes">GSoC 2016: link /dev entries to sysctl nodes</url>
+      <url href="https://wiki.freebsd.org/SummerOfCodeIdeas#Devices_management:_link_.2Fdev_entries_to_sysctl_nodes">GSoC 2016: link <tt>/dev</tt> entries to sysctl nodes</url>
       <url href="https://wiki.freebsd.org/SummerOfCode2016/RethinkLibdevq">GSoC 2016: Redesign libdevq </url>
       <url href="http://planet.freebsd.org/graphics">Graphics Team Blog</url>
     </links>
@@ -1075,7 +1086,8 @@
       <p>The GSoC project about being able to connect a <tt>/dev</tt>
 	entry to <tt>sysctl</tt> nodes is making progress.  After some
 	fruitful discussons on the <a
-	  href="https://lists.freebsd.org/mailman/listinfo/freebsd-arch">freebsd-arch@ mailing-list</a>,
+	  href="https://lists.freebsd.org/mailman/listinfo/freebsd-arch">freebsd-arch@
+	  mailing-list</a>,
 	Kiloreux finished the design and is now implementing the
 	solution.  The GSoC project on <tt>libdevq</tt> was
 	abandoned.</p>
@@ -1090,7 +1102,7 @@
       <ul>
 	<li>There are instances of visual artifacts that appear with
 	  varying frequency, depending on workload.  Of particular
-	  note is lack of redraw when a Qt5 window is partially
+	  note is the lack of redraw when a Qt5 window is partially
 	  covered by a menu and then uncovered.</li>
 
 	<li>WebGL demos will sometimes fail due to a recoverable
@@ -1104,11 +1116,11 @@
 	issues, along with others, by updating Linux support to the
 	point where the Intel GPU Tools work on &os;.</p>
 
-      <p>The Radeon AMD/ATI has been updated to GCN 1.0.  This has
+      <p>The Radeon AMD/ATI driver has been updated to GCN 1.0.  This has
 	only been tested on an R7 240.  2D-accelerated X works.  Due
 	to apparent issues with user library support, X does not
 	recognize the KMS driver as being 3D-capable and reports it as
-	"not DRI2 capable".  The OpenCL benchmark <tt>clpeak</tt>
+	&quot;not DRI2 capable&quot;.  The OpenCL benchmark <tt>clpeak</tt>
 	fails in <tt>drm/ttm</tt>, so there may in fact be issues in
 	the underlying 3D support.</p>
 
@@ -1131,7 +1143,7 @@
     </body>
   </project>
 
-  <project  cat='team'>
+  <project cat='team'>
     <title>&os; IRC Admin Team</title>
 
     <contact>
@@ -1215,10 +1227,10 @@
 	    href="https://wiki.freebsd.org/IRC/Cloaks">IRC
 	    Cloaks</a>.</li>
 
-	<li>Obtain a report on all nicknames and accounts with
+	<li>Obtained a report on all nicknames and accounts with
 	  existing <tt>freebsd/*</tt> user cloaks.</li>
 
-	<li>Liaise with freenode staff on upcoming changes to freebsd
+	<li>Liaised with freenode staff on upcoming changes to freebsd
 	  channels.</li>
       </ul>
 
@@ -1432,7 +1444,7 @@
       <p>Another of Core's important functions is to ensure good
 	relations amongst developers.  To that end, members of Core
 	provided oversight over the backing-out of disputed
-	<tt>blacklistd</tt> related patches to OpenSSH, and acted to
+	<tt>blacklistd</tt>-related patches to OpenSSH, and acted to
 	smooth over ruffled tempers.</p>
 
       <p>This quarter saw the usual quota of gentle reminders to avoid
@@ -1503,7 +1515,7 @@
     </contact>
 
     <body>
-      <p>Since the Triage Team was introduced in the October-December
+      <p>Since the Triage Team was introduced in the October&ndash;December
 	2015 report, it has been working on the following three major
 	aspects of issue triage:</p>
 
@@ -1520,13 +1532,13 @@
       </ul>
 
       <p>Our efforts have almost exclusively focused on issues in the
-	"Ports &amp; Packages" component as that is the easiest
-	starting point.  Other categories like "Base System" require
+	&quot;Ports &amp; Packages&quot; component as that is the easiest
+	starting point.  Other categories like &quot;Base System&quot; require
 	more knowledge and experience with problem content and
 	workflow.</p>
 
       <p>During this time, Rodrigo was inactive due to lack of
-	available time and Vladimir was unable to commit enough time
+	available time, and Vladimir was unable to commit enough time
 	during the first quarter of the year, but provided active
 	contribution during the second.  It became obvious that the
 	Issue Triage Team must concentrate on additional recruitment
@@ -1537,17 +1549,17 @@
 	Wiki page.  A summary of those issues is given here:</p>
 
       <ol>
-	<li>Issue triage, defined as "ensure an issue is summarized,
-	  classified, and assigned to appropriate people", is too time
+	<li>Issue triage, defined as &quot;ensure that an issue is summarized,
+	  classified, and assigned to appropriate people&quot;, is too time
 	  consuming.  Bugzilla automation through auto-assign helps,
 	  but is insufficient.  If the triage process is extended to
-	  include "track the issue through its entire life to
-	  resolution", the time and effort required grows
+	  include &quot;track the issue through its entire life to
+	  resolution&quot;, the time and effort required grows
 	  exponentially.  Fortunately, there are many things the
 	  community can do, with minimum effort, that help greatly.
 	  Part of the recruitment and education process is educating
 	  users on how to properly treat their own issues and issues
-	  they interact with in order to maximize the efficiency of
+	  they interact with, in order to maximize the efficiency of
 	  issue tracking and problem resolution.</li>
 
 	<li>Various timeouts are inadequate.  For example, the
@@ -1577,13 +1589,13 @@
 	  track and quickly find issue categories and, more
 	  importantly, their <strong>states</strong>.  Another example
 	  is ensuring that various flags and keywords are unambiguous
-	  and well understood.  For instance, "patch" and
-	  "patch-ready", can often be misunderstood or
+	  and well understood.  For instance, &quot;patch&quot; and
+	  &quot;patch-ready&quot;, can often be misunderstood or
 	  misapplied.</li>
 
-	<li>Issue statistics are lacking and for the next quarter we
+	<li>Issue statistics are lacking, and for the next quarter we
 	  intend to change that.  Statistics help to provide insight
-	  into potential bottlenecks and inform the priority of
+	  into potential bottlenecks and inform the prioritization of
 	  improvements to the issue tracker and workflows.</li>
       </ol>
     </body>
@@ -1705,7 +1717,8 @@
 	the idea is that building the same binary, software package,
 	document, or other binary artifact twice from the same source
 	produces identical output.  The <a
-	  href="https://reproducible-builds.org/">reproducible-builds.org website</a>
+	  href="https://reproducible-builds.org/">reproducible-builds.org
+	  website</a>
 	provides background information and documentation on making
 	builds reproducible.</p>
 
@@ -1724,7 +1737,7 @@
 	Ed investigated the state of build reproducibility
 	in the ports tree, and presented
 	<i>Reproducible Builds in &os;</i> at BSDCan 2016.  With
-	some work in progress patches, over 80% of the &os; ports tree
+	some work-in-progress patches, over 80% of the &os; ports tree
 	builds reproducibly.</p>
 
       <p>The Diffoscope tool performs in-depth comparison of files,
@@ -1795,11 +1808,11 @@
 	<li>Qt Creator was updated to 3.4.0, 3.5.0, 3.5.1, 3.6.0,
 	  4.0.0, 4.0.1, and 4.0.2.</li>
 
-	<li>Added the new port <tt>misc/qt5-examples</tt> for the
+	<li>A new port <tt>misc/qt5-examples</tt> was added for the
 	  project examples provided by Qt.  This makes Qt Creator more
 	  functional.</li>
 
-	<li>Added the new port <tt>misc/qt5-doc</tt> for Qt's API
+	<li>A new port <tt>misc/qt5-doc</tt> was added for Qt's API
 	  documentation, used by Qt Creator and other programs.</li>
 
 	<li>The base KDE4 ports were updated to 4.14.10.</li>
@@ -1831,7 +1844,6 @@
 	  <given>René</given>
 	  <common>Ladan</common>
 	</name>
-
 	<email>portmgr-secretary@FreeBSD.org</email>
       </person>
 
@@ -1869,7 +1881,7 @@
 	made.</p>
 
       <p>A lot of work was done on modernizing the infrastructure of
-	the Ports Tree, by introducing 6 new <tt>USES</tt>, one new
+	the Ports Tree, by introducing 6 new <tt>USES</tt> knobs, one new
 	keyword, and splitting out the larger targets of
 	<tt>bsd.port.mk</tt> into separate scripts.  There were a
 	total of 42 exp-runs to validate these and other
@@ -1889,7 +1901,7 @@
 	the package building infrastructure.</p>
 
       <p>During BSDCan, <tt>mat</tt> worked on various items,
-	including updating the Porter's Handbook, and  portmgr held a
+	including updating the Porter's Handbook, and portmgr held a
 	meeting to discuss various items.</p>
     </body>
   </project>
@@ -1927,7 +1939,7 @@
 	integrate with <tt>intrng</tt>.</p>
 
       <p>Busdma was updated to handle the cache.  The updated code
-	assumes the device is non-coherent by default, unless the
+	assumes that devices are non-coherent by default, unless the
 	device driver marks the DMA tag as coherent when creating it.
 	The generic and ThunderX PCIe drivers have been updated to
 	create coherent mappings when the device tree marks the
@@ -1935,37 +1947,37 @@
 	the sync operation where it was missing memory barriers.</p>
 
       <p>A number of issues with <tt>hwpmc</tt> have been fixed.  This
-	improves the stability of <tt>hwpmc</tt> on <tt>arm64</tt>
+	improves the stability of <tt>hwpmc</tt> on <tt>arm64</tt>,
 	with no known software issues.  There is a single known issue
-	which seems to be hardware-related, however further testing is
+	which seems to be hardware-related, however, further testing is
 	required.</p>
 
       <p><tt>NEW_PCIB</tt> has been enabled on <tt>arm64</tt>.  This
 	includes handling the <tt>PCI_RES_BUS</tt> resource type.</p>
 
-      <p>Old interfaces replaced before 11 have been removed from the
+      <p>Old interfaces replaced before &os;-11 have been removed from the
 	<tt>arm64</tt> kernel and libraries.  This includes support
 	for compatibility with <tt>libc</tt> from releases prior to
-	11.  The <tt>brk</tt> and <tt>sbrk</tt> functions have also
+	11.0.  The <tt>brk</tt> and <tt>sbrk</tt> functions have also
 	been removed.  This allows a workaround for these functions in
 	the <tt>arm64</tt> C runtime to be removed.</p>
 
       <p><tt>loader.efi</tt> has been updated to use an event timer to
-	implement its internal time function.  This is needed as many
-	UEFI implementations do not handle The <tt>GetTime</tt>
-	runtime service method.  This means <tt>loader.efi</tt> will
+	implement its internal time function.  This is needed, as many
+	UEFI implementations do not handle the <tt>GetTime</tt>
+	runtime service method.  This means that <tt>loader.efi</tt> will
 	now correctly count down before automatically booting.</p>
 
       <p>Initial support for the ARM Juno reference platform has been
 	added.  This hardware is common within ARM, and has been
 	useful for finding assumptions on cpuids.  Booting on the Juno
-	required fixing the kernel to remove the assumption it is
+	required fixing the kernel to remove the assumption that it is
 	booting from CPU zero.  This included assigning cpuids and
 	fixing assumptions within the <tt>GICv2</tt> driver that the
 	cpuid is the same as the <tt>GIC</tt> cpuid.  &os; can now
-	boot on the 4 Cortex-A53 CPUs.  Further investigation is
-	needed to track down why the boot fails when the 2 Cortex-A57
-	CPUs are enabled.</p>
+	boot on the 4 Cortex-A53 CPUs of the Juno board.
+	Further investigation is needed to track down why the boot
+	fails when the 2 Cortex-A57 CPUs are enabled.</p>
 
       <p>Initial work has started on booting &os; on the Pine64 and
 	Raspberry Pi 3 boards.  Both can boot to multiuser mode with
