From: Roland Hieber <r.hieber@pengutronix.de>
To: ptxdist@pengutronix.de
Cc: Roland Hieber <r.hieber@pengutronix.de>
Subject: [ptxdist] [PATCH 2/4] doc: contributing: fix typos, add links, and make text easier to parse
Date: Fri, 5 Oct 2018 11:45:16 +0200 [thread overview]
Message-ID: <20181005094518.29476-2-r.hieber@pengutronix.de> (raw)
In-Reply-To: <20181005094518.29476-1-r.hieber@pengutronix.de>
Signed-off-by: Roland Hieber <r.hieber@pengutronix.de>
---
doc/contributing.rst | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/doc/contributing.rst b/doc/contributing.rst
index 8e2d7883d..1db596c0e 100644
--- a/doc/contributing.rst
+++ b/doc/contributing.rst
@@ -6,13 +6,13 @@ PTXdist Packages
While contributions to all parts of PTXdist are welcome, most contributions
concern individual packages. Here is a checklist of things to look out for
-while creating or updating packages. These are not hard requirements but
+while creating or updating packages. These are not hard requirements, but
there should be good reasons for different choices.
How to Contribute
~~~~~~~~~~~~~~~~~
-Contributions should be sent as patches to the PTXdist mailing list. This
+Contributions should be sent as patches to the :ref:`PTXdist mailing list`. This
is usually done with ``git send-email``.
All patches must contain a descriptive subject and should, for all
@@ -26,11 +26,11 @@ Package Builds should be Reproducible
Many packages autodetect which features are available. As a result, the
exact features of a package may depend on the build host and the build
-order of the packages. To avoid this autodetection must be restricted as
+order of the packages. To avoid this, autodetection must be restricted as
much as possible.
For **autoconf** based packages, the first step is to specify all relevant
-``configure`` options. The :ref:`configure_helper` scripts can help filter
+``configure`` options. The :ref:`configure_helper` script can help filter
out the unimportant options.
There are also cache variables that can be used to enforce the outcome of
@@ -55,17 +55,17 @@ Packages Suboptions
Suboptions for PTXdist packages are useful to make parts of the package
optional. However, it is not always easy to decide what should be optional
-and how to map the build system options to packages suboptions. Here are a
+and how to map the build system options to package suboptions. Here are a
few guidelines to help with that.
- Avoid unnecessary suboptions. When in doubt, use the package default or
what other distributions use. If the creator of the package does not
- know what to choose then the user wont either.
+ know what to choose, then the user won't either.
- Use suboptions to save disk space. If a feature adds extra dependencies
- or uses a lot of space then a suboptions is useful to save the disk
+ or uses a lot of space then a suboption is useful to save disk
space when the feature is not needed.
- Try to create high-level options. Some packages have very low-level
- build options with very few useful combinations. Try to define
+ build options with very few useful combinations. Try to distill the
high-level features or use-cases and define options for those.
- Options for new use-cases can always be added later. It's perfectly
acceptable to just disable some unused features when creating a new
@@ -78,19 +78,20 @@ The most common contribution to PTXdist are new versions for existing
packages. This is usually quite simple, but there are a few things to keep
in mind:
-- New versions can have new build system options that should be used.
+- New versions can have new build system options that should be set for
+ reproducible builds.
:ref:`configure_helper` can be used to find the new options.
-- There may be patches for the old version. Make sure they are update as
- well or removed if they are no longer needed.
+- There may be patches for the old version. Make sure they are updated as
+ well, or removed if they are no longer needed.
Misc
~~~~
-For new Packages, the top-level option and any non-obvious suboption should
+For new packages, the top-level option and any non-obvious suboptions should
have a help text. The homepage of a package or the package description from
-other distributions a usually a good inspiration.
+other distributions are usually a good inspiration.
-The package templates to create new packages contain commented out default
+For new packages, the generated templates contain commented-out default
sections. These are meant as a helper to simplify creating custom stages.
Any remaining default stages must be removed.
@@ -119,7 +120,7 @@ needed. This tool contains a blacklist to filter out these options.
``-h, --help``
Show the help message and exit
-``-p <pgk>, --pkg <pgk>``
+``-p <pkg>, --pkg <pkg>``
The ptxdist package to check
``-o <old>, --old-src <old>``
--
2.19.0
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
next prev parent reply other threads:[~2018-10-05 9:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-05 9:45 [ptxdist] [PATCH 1/4] doc: dev_manual: improve Patch Series section Roland Hieber
2018-10-05 9:45 ` Roland Hieber [this message]
2018-10-05 10:02 ` [ptxdist] [PATCH 2/4] doc: contributing: fix typos, add links, and make text easier to parse Roland Hieber
2018-10-05 9:45 ` [ptxdist] [PATCH 3/4] doc: getting help: prune section with only one subsection Roland Hieber
2018-10-05 9:45 ` [ptxdist] [PATCH 4/4] doc: environment: general proof-reading and copy editing Roland Hieber
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=20181005094518.29476-2-r.hieber@pengutronix.de \
--to=r.hieber@pengutronix.de \
--cc=ptxdist@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox