All of lore.kernel.org
 help / color / mirror / Atom feed
From: "akuster" <akuster808@gmail.com>
To: "rpjday@crashcourse.ca" <rpjday@crashcourse.ca>,
	Yocto discussion list <yocto@yoctoproject.org>
Subject: Re: [yocto] [PATCH] overview-manual: chs 1-3, various minor tweaks/cleanups
Date: Tue, 11 Feb 2020 12:10:57 -0800	[thread overview]
Message-ID: <0b255455-ff99-7853-c43d-561ac6b02ebc@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.21.2002111415130.53570@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 8135 bytes --]



On 2/11/20 11:16 AM, rpjday@crashcourse.ca wrote:
> Minor fixes:
>
>   - punctuation
>   - capitalization
>   - markup
>   - wording
>
> Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

Wrong ML. We have a docs@lists.yoctoproject.org with patchwork support.

- armin
>
> ---
>
> diff --git a/documentation/overview-manual/overview-manual-development-environment.xml b/documentation/overview-manual/overview-manual-development-environment.xml
> index 2f1bd1610..dd12814fc 100644
> --- a/documentation/overview-manual/overview-manual-development-environment.xml
> +++ b/documentation/overview-manual/overview-manual-development-environment.xml
> @@ -69,7 +69,7 @@
>      <title>The Development Host</title>
>
>      <para>
> -        A development host or
> +        A <firstterm>development host</firstterm> or
>          <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>
>          is key to using the Yocto Project.
>          Because the goal of the Yocto Project is to develop images or
> @@ -389,7 +389,7 @@
>          In summary, a single point of entry
>          exists for changes into a "master" or development branch of the
>          Git repository, which is controlled by the project’s maintainer.
> -        And, a set of developers exist who independently develop, test, and
> +        In addition, a set of developers exist who independently develop, test, and
>          submit changes to "contrib" areas for the maintainer to examine.
>          The maintainer then chooses which changes are going to become a
>          permanent part of the project.
> diff --git a/documentation/overview-manual/overview-manual-yp-intro.xml b/documentation/overview-manual/overview-manual-yp-intro.xml
> index dbf62cc16..87b7e40b3 100644
> --- a/documentation/overview-manual/overview-manual-yp-intro.xml
> +++ b/documentation/overview-manual/overview-manual-yp-intro.xml
> @@ -89,7 +89,7 @@
>                          Additionally, if you have used the Yocto Project to
>                          create an image or application and you find yourself
>                          not able to support it, commercial Linux vendors such
> -                        as Wind River, Mentor Graphics, Timesys, and ENEA could
> +                        as Wind River, Mentor Graphics, Timesys, and Enea could
>                          take it and provide ongoing support.
>                          These vendors have offerings that are built using
>                          the Yocto Project.
> @@ -127,7 +127,7 @@
>                          not part of a standard toolchain, you can easily
>                          customize that toolchain through specification of
>                          platform-specific tuning parameters.
> -                        And, should you need to use a third-party toolchain,
> +                        In addition, should you need to use a third-party toolchain,
>                          mechanisms built into the Yocto Project allow for that.
>                          </para></listitem>
>                      <listitem><para>
> @@ -273,7 +273,7 @@
>                          <emphasis>Initial Build Times Can be Significant:</emphasis>
>                          Long initial build times are unfortunately unavoidable
>                          due to the large number of packages initially built
> -                        from scratch for a fully functioning Linux system.
> +                        from scratch for a fully-functioning Linux system.
>                          Once that initial build is completed, however, the
>                          shared-state (sstate) cache mechanism Yocto Project
>                          uses keeps the system from rebuilding packages that
> @@ -358,7 +358,7 @@
>              To illustrate how layers are used to keep things modular, consider
>              machine customizations.
>              These types of customizations typically reside in a special layer,
> -            rather than a general layer, called a BSP Layer.
> +            rather than a general layer, called a <firstterm>BSP layer</firstterm>.
>              Furthermore, the machine customizations should be isolated from
>              recipes and Metadata that support a new GUI environment,
>              for example.
> @@ -852,9 +852,9 @@
>          </para>
>
>          <para>
> -            This section provides an introduction to the choices or
> +            This section provides an introduction to the choices of
>              development methods you have when setting up your Build Host.
> -            Depending on the your particular workflow preference and the
> +            Depending on your particular workflow preference and the
>              type of operating system your Build Host runs, several choices
>              exist that allow you to use the Yocto Project.
>              <note>
> @@ -1013,7 +1013,7 @@
>          </para>
>
>          <para>
> -            Poky has a regular, well established, six-month release cycle
> +            Poky has a regular, well-established, six-month release cycle
>              under its own version.
>              Major releases occur at the same time major releases (point
>              releases) occur for the Yocto Project, which are typically in the
> @@ -1104,7 +1104,7 @@
>                      select (DEB, RPM, or IPK) is used to roll up the software.
>                      </para></listitem>
>                  <listitem><para>
> -                    Different QA and sanity checks run throughout entire
> +                    Different QA and sanity checks run throughout the entire
>                      build process.
>                      </para></listitem>
>                  <listitem><para>
> @@ -1145,7 +1145,7 @@
>                      user-defined variables, and hardware configuration
>                      information.
>                      These files tell the
> -                    <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink>
> +                    <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>
>                      what to build and what to put into the image to support a
>                      particular platform.
>                      </para></listitem>
> @@ -1177,7 +1177,7 @@
>                      <para>For more detailed information on layers, see the
>                      "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
>                      section in the Yocto Project Development Tasks Manual.
> -                    For a discussion specifically on BSP Layers, see the
> +                    For a discussion specifically on BSP layers, see the
>                      "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
>                      section in the Yocto Project Board Support Packages (BSP)
>                      Developer's Guide.
> @@ -1234,7 +1234,7 @@
>                      developed by the OpenEmbedded community that has been
>                      pared down into a smaller, core set of continuously
>                      validated recipes.
> -                    The result is a tightly controlled and quality-assured
> +                    The result is a tightly-controlled and quality-assured
>                      core set of recipes.</para>
>
>                      <para>You can see the Metadata in the
> @@ -1303,7 +1303,7 @@
>                      patches to apply.
>                      Recipes describe dependencies for libraries or for other
>                      recipes as well as configuration and compilation options.
> -                    Related recipes are consolidated into a layer.
> +                    Related recipes are typically consolidated into a layer.
>                      </para></listitem>
>              </itemizedlist>
>          </para>
>
>
> 


[-- Attachment #2: Type: text/html, Size: 9116 bytes --]

      reply	other threads:[~2020-02-11 20:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11 19:16 [PATCH] overview-manual: chs 1-3, various minor tweaks/cleanups rpjday
2020-02-11 20:10 ` akuster [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0b255455-ff99-7853-c43d-561ac6b02ebc@gmail.com \
    --to=akuster808@gmail.com \
    --cc=rpjday@crashcourse.ca \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.