Date: Wed, 9 Apr 2014 14:38:38 +0000 (UTC) From: Christian Brueffer <brueffer@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44505 - head/en_US.ISO8859-1/htdocs/news/status Message-ID: <201404091438.s39EccmW076246@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: brueffer Date: Wed Apr 9 14:38:38 2014 New Revision: 44505 URL: http://svnweb.freebsd.org/changeset/doc/44505 Log: Spelling, grammar and language fixes. Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2014-01-2014-03.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2014-01-2014-03.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2014-01-2014-03.xml Wed Apr 9 14:32:06 2014 (r44504) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2014-01-2014-03.xml Wed Apr 9 14:38:38 2014 (r44505) @@ -1093,11 +1093,11 @@ <body> <p>Chromebook is an ARMv7 Cortex-A15 personal computer powered by Samsung Exynos 5 Dual System-on-Chip. As of the current status - of this project, such laptop can be booted with &os; from USB - flash — it works stable (including SMP) and it can build - third-party applications. Display and keyboard works.</p> + of this project, such laptops can be booted with &os; from USB + flash — it works stably (including SMP) and it can build + third-party applications. The display and keyboard work.</p> - <p>Thank &a.grehan; for providing hardware.</p> + <p>Thanks to &a.grehan; for providing hardware.</p> </body> <help> @@ -1153,7 +1153,7 @@ <p>&a.emaste; reviewed some CI work that &a.rodrigc; had done for the FreeNAS project with Jenkins, and encouraged him to set up something similar for the &os; Project. With the help of the - &os; Cluster Administration Team, He set up a &os; machine + &os; Cluster Administration Team, he set up a &os; machine running two bhyve virtual machines, <tt>jenkins-9.FreeBSD.org</tt> and <tt>jenkins-10.FreeBSD.org</tt>. He set up software builds of @@ -1206,7 +1206,7 @@ libpam4j does not currently work on &os;.</li> <li>&a.lwhsu; maintains the <tt>devel/jenkins</tt> port. He set - up a Jenkins build which rans the scan-build static analyzer + up a Jenkins build which runs the scan-build static analyzer which is part of LLVM.</li> <li>&a.skreuzer; has experience administering Jenkins systems. @@ -1225,7 +1225,7 @@ <li>&a.swills; maintains the <tt>devel/jenkins-lts</tt> port. He has implemented several builds at <tt>jenkins.FreeBSD.org</tt> which detect commits to the &os; ports repository, and then - builds the ports tree using Poudrière.</li> + build the ports tree using Poudrière.</li> </ul> <p>At the end of March, &a.novel; reported to @@ -1289,7 +1289,7 @@ affecting Dell Equallogic users.</p> <p>There have also been numerous enhancements, such as support for - redirections, which are neccessary for some High Availability + redirections, which are necessary for some High Availability setups, and the ability to modify session parameters in the iscsictl utility. Previously it was necessary to remove the session and add it again.</p> @@ -1381,7 +1381,7 @@ device vt_efifb</pre> works.</li> <li>IA64 — untested.</li> <li>MIPS — untested.</li> - <li>PPC and PPC64 — works, but without X.Org yet.</li> + <li>PPC and PPC64 — work, but without X.Org yet.</li> <li>SPARC — works on certain hardware (e.g., Ultra 5).</li> <li><tt>vesa(4)</tt> — in progress.</li> <li>i386/amd64 nVidia driver — not supported. VGA should @@ -1430,7 +1430,7 @@ device vt_efifb</pre> stage, and a call for testing is expected in the next month. The userspace portion consists of the <tt>automountd(8)</tt> daemon, which is designed to be fully compatible with its - counterpart in OS X, Solaris, and Linux, and which is nearly + counterparts in OS X, Solaris, and Linux, and which is nearly complete. Work on the kernel component continues.</p> </body> @@ -1521,14 +1521,14 @@ device vt_efifb</pre> providing simple networking using bridges between guest VMs.</li> - <li>QEMU might also be used instead of the bhyve this way.</li> + <li>QEMU might also be used instead of bhyve this way.</li> <li>The main goal on the networking side is to use OpenContrail solution, compliant with the modern OpenStack networking API ("neutron").</li> </ul> - <p>Also, initial port of the OpenContrail vRouter kernel module + <p>Also, an initial port of the OpenContrail vRouter kernel module has been completed. It successfully handles all networking on the host.</p> </body> @@ -1550,7 +1550,7 @@ device vt_efifb</pre> </contact> <body> - <p>The project to update the Intel grapics chipset driver + <p>The project to update the Intel graphics chipset driver (<tt>i915kms</tt>) to a recent snapshot of the Linux upstream code continues. Progress was delayed by external circumstances, but it is hoped to reach a useful milestone in the near @@ -1684,7 +1684,7 @@ device vt_efifb</pre> within this quarterly status report.</p> <p>We were a Gold Sponsor for NYCBSDCon 2014 in New York, - February 8, which was attended by sSeveral board members. We + February 8, which was attended by several board members. We were represented at SCALE in Los Angeles, February 22-23, and ICANN in Singapore, March 22-25.</p> @@ -1753,7 +1753,7 @@ device vt_efifb</pre> </links> <body> - <p>LLDB is the the debugger project in the associated with + <p>LLDB is the debugger project associated with Clang/LLVM. It supports the Mac OS X, Linux, and &os; platforms, with ongoing work on Windows. It builds on existing components in the larger LLVM project, for example using Clang's expression @@ -1786,7 +1786,7 @@ device vt_efifb</pre> <p>LLDB is currently not yet built by default and may be enabled by adding <tt>WITH_LLDB=</tt> to <tt>src.conf(5)</tt>. A port - will be made available for those wo wish to track ongoing + will be made available for those who wish to track ongoing development more closely.</p> </body> @@ -1831,14 +1831,14 @@ device vt_efifb</pre> reliably.</p> <p>The daemon now supports client-side certificates, which can be - used to automatically configure receiver side — directory + used to automatically configure the receiver side — the directory name for received trail files is determined based on the <tt>commonName</tt> field in client's certificate. There is no - need anymore to add every sender to receiver's configuration + need anymore to add every sender to the receiver's configuration file.</p> <p>The sender's functionality was extended to allow sending audit - trail files to multile receivers.</p> + trail files to multiple receivers.</p> <p>Complete Public Key Infrastructure (PKI) support is now implemented, including full certificate chain verification, @@ -1883,18 +1883,18 @@ device vt_efifb</pre> <p>SDIO card detection and initialization already work, most needed bus methods are implemented and tested.</p> - <p>WiFi driver is able to load a firmware onto the card and + <p>The WiFi driver is able to load a firmware onto the card and initialize it. Migration of the MMC stack to the new locking model is necessary in order to work with SDIO cards effectively. The &os; CAM implementation is believed to be a good choice. - There is an ongoing work to implement an MMC transport for + There is ongoing work to implement an MMC transport for CAM.</p> </body> <help> <task>SDIO stack: finish CAM migration. The XPT layer is almost ready, what is missing is a SIM module, for which a modified - version of SDHCI controller driver will be used, and a + version of the SDHCI controller driver will be used, and a peripheral module, where porting the <tt>mmcsd(4)</tt> driver is required.</task> @@ -1959,7 +1959,7 @@ device vt_efifb</pre> in the Ports Collection after GNOME 3 has been merged.</p> <p>MATE 1.8 was released at the beginning of April, Eric Turgeon - of GhostBSD is volunteered to do that update for &os;. Note + of GhostBSD had volunteered to do that update for &os;. Note that this update is still based on GTK+, version 2. The GTK+ 3-based MATE is on the roadmap for 1.10.</p> </body> @@ -2239,10 +2239,10 @@ device vt_efifb</pre> </contact> <body> - <p>Not all of the &os; changes to GC have been reflected upstream. + <p>Not all of the &os; changes to GCC have been reflected upstream. A large amount of the platform support as well as a couple minor improvements like the kernel formatting checker need to be - forwarded ported (and if possible, moved upstream in to + forward ported (and if possible, moved upstream into GCC).</p> <p>We will be targeting the &os; ports tree <tt>lang/gcc*</tt>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404091438.s39EccmW076246>