[Buildroot] [PATCH 0 of 7] manual: rework Contributing chapter

[Buildroot] [PATCH 0 of 7] manual: rework Contributing chapter

[Thomas De Schampheleire]

This patch series reworks the "Contributing to Buildroot" chapter in the
manual. According to the latest Buildroot Developer Days, we want to promote
contributions that are not feature patches, like fixing autobuild failures,
closing bugs, working on items from the TODO list, etc. This series reorders
and expands the chapter with that desire in mind.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v2:
- integrate rewording comments by Yann, Samuel and Arnout (thanks!)
- add new patch modifying the commit message template

[Buildroot] [PATCH 1 of 7] manual: contributing: move and expand autobuild section

[Thomas De Schampheleire]

This patch moves the section about autobuild fixing up, and expands it with
more details about what autobuilds are, and how you can help with it.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v2: mention the br-reproduce-build script (Yann)

 docs/manual/contribute.txt |  63 ++++++++++++++++++++++++++++++-----------
 1 files changed, 46 insertions(+), 17 deletions(-)

diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
--- a/docs/manual/contribute.txt
+++ b/docs/manual/contribute.txt
@@ -33,6 +33,52 @@ help in reproducing, analyzing and fixin
 welcome. Don't hesitate to add a comment to bug reports reporting your
 findings, even if you don't yet see the full picture.
 
+Analyzing and fixing autobuild failures
+---------------------------------------
+
+The Buildroot autobuilders are a set of build machines that continuously
+run Buildroot builds based on random configurations. This is done for
+all architectures supported by Buildroot, with various toolchains, and
+with a random selection of packages. With the large commit activity on
+Buildroot, these autobuilders are a great help in detecting problems
+very early after commit.
+
+All build results are available at http://autobuild.buildroot.org[],
+statistics are at http://autobuild.buildroot.org/stats.php[]. Every day,
+an overview of all failed packages is sent to the mailing list.
+
+Detecting problems is great, but obviously these problems have to be
+fixed as well. Your contribution is very welcome here! There are
+basically two things that can be done:
+
+- Analyzing the problems. The daily summary mails do not contain details
+  about the actual failures: in order to see what's going on you have to
+  open the build log and check the last output. Having someone doing
+  this for all packages in the mail is very useful for other developers,
+  as they can make a quick initial analysis based on this output alone.
+
+- Fixing a problem. When fixing autobuild failures, you should follow
+  these steps:
+  . Check if you can reproduce the problem by building with the same
+    configuration. You can do this manually, or use the
+    http://git.buildroot.org/buildroot-test/tree/utils/br-reproduce-build[br-reproduce-build]
+    script that will automatically clone a Buildroot git repository,
+    checkout the correct revision, download and set the right
+    configuration, and start the build.
+  . Analyze the problem and create a fix.
+  . Verify that the problem is really fixed by starting from a clean
+    Buildroot tree and only applying your fix.
+  . Send the fix to the Buildroot mailing list (see
+    xref:submitting-patches[]). In case you created a patch against the
+    package sources, you should also send the patch upstream so that the
+    problem will be fixed in a later release, and the patch in Buildroot
+    can be removed.
+    In the commit message of a patch fixing an autobuild failure, add a
+    reference to the build result directory, as follows:
+---------------------
+Fixes http://autobuild.buildroot.org/results/51000a9d4656afe9e0ea6f07b9f8ed374c2e4069
+---------------------
+
 [[submitting-patches]]
 Submitting patches
 ------------------
@@ -210,23 +256,6 @@ Buildroot's Patchwork website can be use
 purposes. Please see xref:apply-patches-patchwork[] for more
 information on using Buildroot's Patchwork website to apply patches.
 
-Autobuild
----------
-
-The Buildroot community is currently setting up automatic builds in
-order to test more and more configurations. All build results are
-available at http://autobuild.buildroot.org[]
-
-A good way to contribute is by fixing broken builds.
-
-In the commit message of a patch fixing an _autobuild_, add a
-reference to the _build result directory_ (the +dir+ link in the _data
-column_):
-
----------------------
-Fixes http://autobuild.buildroot.org/results/51000a9d4656afe9e0ea6f07b9f8ed374c2e4069
----------------------
-
 [[reporting-bugs]]
 Reporting issues/bugs, get help
 -------------------------------

[Buildroot] [PATCH 1 of 7] manual: contributing: move and expand autobuild section

[Samuel Martin]

On Thu, Mar 6, 2014 at 11:07 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> This patch moves the section about autobuild fixing up, and expands it with
> more details about what autobuilds are, and how you can help with it.
>
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Acked-by: Samuel Martin <s.martin49@gmail.com>

Regards,

-- 
Samuel

[Buildroot] [PATCH 2 of 7] manual: contributing: move section on patch reviews up and change intro

[Thomas De Schampheleire]

This patch moves the section about patch reviews and the
Tested-by/Reviewed-by/Acked-by tags upwards. Additionally, the first
paragraph is removed and replaced by another one. There are no other changes
in the text.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

---
v2: fix indentation of Acked-by paragraph (Samuel), some rephrasing (Arnout)

 docs/manual/contribute.txt |  127 ++++++++++++++++++++--------------------
 1 files changed, 65 insertions(+), 62 deletions(-)

diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
--- a/docs/manual/contribute.txt
+++ b/docs/manual/contribute.txt
@@ -79,6 +79,74 @@ basically two things that can be done:
 Fixes http://autobuild.buildroot.org/results/51000a9d4656afe9e0ea6f07b9f8ed374c2e4069
 ---------------------
 
+Reviewing and testing patches
+-----------------------------
+
+With the amount of patches sent to the mailing list each day, the
+maintainer has a very hard job to judge which patches are ready to apply
+and which ones aren't. Contributors can greatly help here by reviewing
+and testing these patches.
+
+In the review process, do not hesitate to respond to patch submissions
+for remarks, suggestions or anything that will help everyone to
+understand the patches and make them better. Please use internet
+style replies in plain text emails when responding to patch
+submissions.
+
+To indicate approval of a patch, there are three formal tags that keep
+track of this approval. To add your tag to a patch, reply to it with the
+approval tag below the original author's Signed-off-by line. These tags
+will be picked up automatically by patchwork (see
+ref:apply-patches-patchwork[]) and will be part of the commit log when
+the patch is accepted.
+
+Tested-by:: Indicates that the patch has been tested successfully.
+  You are encouraged to specify what kind of testing you performed
+  (compile-test on architecture X and Y, runtime test on target A,
+  ...). This additional information helps other testers and the
+  maintainer.
+
+Reviewed-by:: Indicates that you code-reviewed the patch and did your
+  best in spotting problems, but you are not sufficiently familiar with
+  the area touched to provide an Acked-by tag. This means that there
+  may be remaining problems in the patch that would be spotted by
+  someone with more experience in that area. Should such problems be
+  detected, your Reviewed-by tag remains appropriate and you cannot
+  be blamed.
+
+Acked-by:: Indicates that you code-reviewed the patch and you are
+  familiar enough with the area touched to feel that the patch can be
+  committed as-is (no additional changes required). In case it later
+  turns out that something is wrong with the patch, your Acked-by could
+  be considered inappropriate. The difference between Acked-by and
+  Reviewed-by is thus mainly that you are prepared to take the blame on
+  Acked patches, but not on Reviewed ones.
+
+If you reviewed a patch and have comments on it, you should simply reply
+to the patch stating these comments, without providing a Reviewed-by or
+Acked-by tag. These tags should only be provided if you judge the patch
+to be good as it is.
+
+It is important to note that neither Reviewed-by nor Acked-by imply
+that testing has been performed. To indicate that you both reviewed and
+tested the patch, provide two separate tags (Reviewed/Acked-by and
+Tested-by).
+
+Note also that _any developer_ can provide Tested/Reviewed/Acked-by
+tags, without exception, and we encourage everyone to do this. Buildroot
+does not have a defined group of _core_ developers, it just so happens
+that some developers are more active than others. The maintainer will
+value tags according to the track record of their submitter. Tags
+provided by a regular contributor will naturally be trusted more than
+tags provided by a newcomer. As you provide tags more regularly, your
+'trustworthiness' (in the eyes of the maintainer) will go up, but _any_
+tag provided is valuable.
+
+Buildroot's Patchwork website can be used to pull in patches for testing
+purposes. Please see xref:apply-patches-patchwork[] for more
+information on using Buildroot's Patchwork website to apply patches.
+
+
 [[submitting-patches]]
 Submitting patches
 ------------------
@@ -194,68 +262,6 @@ This can be easily handled with +git for
     -M -o outgoing origin/master
 ---------------------
 
-Reviewing/Testing patches
--------------------------
-
-The review process for new patches is done over the mailing list. Once
-a patch is submitted to the mailing list, other developers will provide
-feedback to the patch via emails sent through the mailing list.
-
-In the review process, do not hesitate to respond to patch submissions
-for remarks, suggestions or anything that will help everyone to
-understand the patches and make them better. Please use internet
-style replies in plain text emails when responding to patch
-submissions.
-
-Some tags are used to help following the state of any patch posted on
-the mailing-list:
-
-Tested-by:: Indicates that the patch has been tested in one way or
-  another. You are encouraged to specify what kind of testing you
-  performed (compile-test on architecture X and Y, runtime test on
-  target A, ...). This additional information helps other testers and
-  the maintainer.
-
-Reviewed-by:: Indicates that you code-reviewed the patch and did your
-  best in spotting problems, but you are not sufficiently familiar with
-  the area touched to provide an Acked-by tag. This means that there
-  may be remaining problems in the patch that would be spotted by
-  someone with more experience in that area. Should such problems be
-  detected, your Reviewed-by tag remains appropriate and you cannot
-  be blamed.
-
-Acked-by:: Indicates that you code-reviewed the patch and you are
-familiar enough with the area touched to feel that the patch can be
-committed as-is (no additional changes required). In case it later turns
-out that something is wrong with the patch, your Acked-by could be
-considered inappropriate. The difference between Acked-by and
-Reviewed-by is thus mainly that you are prepared to take the blame on
-Acked patches, but not on Reviewed ones.
-
-If you reviewed a patch and have comments on it, you should simply reply
-to the patch stating these comments, without providing a Reviewed-by or
-Acked-by tag. These tags should only be provided if you judge the patch
-to be good as it is.
-
-It is important to note that neither Reviewed-by nor Acked-by imply
-that testing has been performed. To indicate that you both reviewed and
-tested the patch, provide two separate tags (Reviewed/Acked-by and
-Tested-by).
-
-Note also that _any developer_ can provide Tested/Reviewed/Acked-by
-tags, without exception, and we encourage everyone to do this. Buildroot
-does not have a defined group of _core_ developers, it just so happens
-that some developers are more active than others. The maintainer will
-value tags according to the track record of their submitter. Tags
-provided by a regular contributor will naturally be trusted more than
-tags provided by a newcomer. As you provide tags more regularly, your
-'trustworthiness' (in the eyes of the maintainer) will go up, but _any_
-tag provided is valuable.
-
-Buildroot's Patchwork website can be used to pull in patches for testing
-purposes. Please see xref:apply-patches-patchwork[] for more
-information on using Buildroot's Patchwork website to apply patches.
-
 [[reporting-bugs]]
 Reporting issues/bugs, get help
 -------------------------------

[Buildroot] [PATCH 2 of 7] manual: contributing: move section on patch reviews up and change intro

[Samuel Martin]

On Thu, Mar 6, 2014 at 11:07 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> This patch moves the section about patch reviews and the
> Tested-by/Reviewed-by/Acked-by tags upwards. Additionally, the first
> paragraph is removed and replaced by another one. There are no other changes
> in the text.
>
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Acked-by: Samuel Martin <s.martin49@gmail.com>

Regards,

-- 
Samuel

[Buildroot] [PATCH 3 of 7] manual: contributing: add section on TODO list

[Thomas De Schampheleire]

This patch adds a small section about working on items from the TODO list.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v2: add empty line after section title (Yann)

 docs/manual/contribute.txt |  9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
--- a/docs/manual/contribute.txt
+++ b/docs/manual/contribute.txt
@@ -146,6 +146,15 @@ Buildroot's Patchwork website can be use
 purposes. Please see xref:apply-patches-patchwork[] for more
 information on using Buildroot's Patchwork website to apply patches.
 
+Work on items from the TODO list
+--------------------------------
+
+If you want to contribute to Buildroot but don't know where to start,
+and you don't like any of the above topics, you can always work on items
+from the http://elinux.org/Buildroot#Todo_list[Buildroot TODO list].
+Don't hesitate to discuss an item first on the mailing list or on IRC.
+Do edit the wiki to indicate when you start working on an item, so we
+avoid duplicate efforts.
 
 [[submitting-patches]]
 Submitting patches

[Buildroot] [PATCH 3 of 7] manual: contributing: add section on TODO list

[Samuel Martin]

On Thu, Mar 6, 2014 at 11:07 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> This patch adds a small section about working on items from the TODO list.
>
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Acked-by: Samuel Martin <s.martin49@gmail.com>

>
> ---
> v2: add empty line after section title (Yann)
>
>  docs/manual/contribute.txt |  9 +++++++++
>  1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
> --- a/docs/manual/contribute.txt
> +++ b/docs/manual/contribute.txt
> @@ -146,6 +146,15 @@ Buildroot's Patchwork website can be use
>  purposes. Please see xref:apply-patches-patchwork[] for more
>  information on using Buildroot's Patchwork website to apply patches.
>
> +Work on items from the TODO list
> +--------------------------------
> +
> +If you want to contribute to Buildroot but don't know where to start,
> +and you don't like any of the above topics, you can always work on items
> +from the http://elinux.org/Buildroot#Todo_list[Buildroot TODO list].
> +Don't hesitate to discuss an item first on the mailing list or on IRC.
> +Do edit the wiki to indicate when you start working on an item, so we
> +avoid duplicate efforts.
>
>  [[submitting-patches]]
>  Submitting patches
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Regards,

-- 
Samuel

[Buildroot] [PATCH 4 of 7] manual: contributing: minor rewording of 'submitting patches' section

[Thomas De Schampheleire]

This patch makes some minor changes to the section about submitting patches.
Content-wise there are little changes.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Samuel Martin <s.martin49@gmail.com>

---
v2: no changes

 docs/manual/contribute.txt |  20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
--- a/docs/manual/contribute.txt
+++ b/docs/manual/contribute.txt
@@ -164,16 +164,18 @@ Submitting patches
 _Please, do not attach patches to bugs, send them to the mailing list
 instead_.
 
-When your changes are done, and committed in your local git view,
-_rebase_ your development branch on top of the upstream tree before
-generating the patch set. To do so, run:
+If you made some changes to Buildroot and you would like to contribute
+them to the Buildroot project, proceed as follows. Starting from the
+changes committed in your local git view, _rebase_ your development
+branch on top of the upstream tree before generating a patch set. To do
+so, run:
 
 ---------------------
 $ git fetch --all --tags
 $ git rebase origin/master
 ---------------------
 
-Here, you are ready to generate then submit your patch set.
+Now, you are ready to generate then submit your patch set.
 
 To generate it, run:
 
@@ -185,7 +187,7 @@ This will generate patch files in the +o
 automatically adding the +Signed-off-by+ line.
 
 Once patch files are generated, you can review/edit the commit message
-before submitting them using your favorite text editor.
+before submitting them, using your favorite text editor.
 
 Lastly, send/submit your patch set to the Buildroot mailing list:
 
@@ -196,9 +198,9 @@ Lastly, send/submit your patch set to th
 Note that +git+ should be configured to use your mail account.
 To configure +git+, see +man git-send-email+ or google it.
 
-Make sure posted *patches are not line-wrapped*, otherwise they cannot
-easily be applied. In such a case, fix your e-mail client, or better,
-use +git send-email+ to send your patches.
+If you do not use +git send-email+, make sure posted *patches are not
+line-wrapped*, otherwise they cannot easily be applied. In such a case,
+fix your e-mail client, or better yet, learn to use +git send-email+.
 
 Cover letter
 ~~~~~~~~~~~~
@@ -244,7 +246,7 @@ Hereafter the recommended layout:
 ---------------
 Patch title less than 80-character length
 
-Some more paragraph giving some more details.
+A paragraph giving more details.
 
 And yet another paragraph giving more details.
 

[Buildroot] [PATCH 5 of 7] manual: contributing: don't recommend leaving out changelog from patches

[Thomas De Schampheleire]

Currently, the manual states that if you send a series and include a
changelog in the introduction mail (0 of x), it is not necessary to include
a changelog on the individual patches.
This is not always convenient: for large patch series it requires going back
to the introduction mail when opening each patch, to understand what
changed.
This patch rewords the paragraph accordingly.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v2: remove personal statements from commit message (Yann)

 docs/manual/contribute.txt |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
--- a/docs/manual/contribute.txt
+++ b/docs/manual/contribute.txt
@@ -228,8 +228,8 @@ Patch revision changelog
 When improvements are requested, the new revision of each commit
 should include a changelog of the modifications between each
 submission. Note that when your patch series is introduced by a cover
-letter, the changelog may be added in the cover letter rather than in
-the individual commits.
+letter, an overall changelog may be added to the cover letter in
+addition to the changelog in the individual commits.
 
 When added to the individual commits, this changelog is added when
 editing the commit message.  Below the +Signed-off-by+ section, add

[Buildroot] [PATCH 5 of 7] manual: contributing: don't recommend leaving out changelog from patches

[Samuel Martin]

On Thu, Mar 6, 2014 at 11:07 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Currently, the manual states that if you send a series and include a
> changelog in the introduction mail (0 of x), it is not necessary to include
> a changelog on the individual patches.
> This is not always convenient: for large patch series it requires going back
> to the introduction mail when opening each patch, to understand what
> changed.
> This patch rewords the paragraph accordingly.
>
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Acked-by: Samuel Martin <s.martin49@gmail.com>

>
> ---
> v2: remove personal statements from commit message (Yann)
>
>  docs/manual/contribute.txt |  4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
> --- a/docs/manual/contribute.txt
> +++ b/docs/manual/contribute.txt
> @@ -228,8 +228,8 @@ Patch revision changelog
>  When improvements are requested, the new revision of each commit
>  should include a changelog of the modifications between each
>  submission. Note that when your patch series is introduced by a cover
> -letter, the changelog may be added in the cover letter rather than in
> -the individual commits.
> +letter, an overall changelog may be added to the cover letter in
> +addition to the changelog in the individual commits.
>
>  When added to the individual commits, this changelog is added when
>  editing the commit message.  Below the +Signed-off-by+ section, add
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

,Regards

-- 
Samuel

[Buildroot] [PATCH 6 of 7] manual: contributing: minor rewording of 'reporting bugs' section

[Thomas De Schampheleire]

This patch makes some minor fixes in the section about reporting bugs.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v2: provide an explicit list of 'good' pastebins (Yann)

 docs/manual/contribute.txt |  21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

Although I don't think this section belongs in the Contributing chapter,
there currently isn't a better place. When I get to rethinking the manual
structure, this can be changed.

diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
--- a/docs/manual/contribute.txt
+++ b/docs/manual/contribute.txt
@@ -274,16 +274,16 @@ This can be easily handled with +git for
 ---------------------
 
 [[reporting-bugs]]
-Reporting issues/bugs, get help
--------------------------------
+Reporting issues/bugs or getting help
+-------------------------------------
 
 Before reporting any issue, please check
 xref:mailing-list-subscribe[the mailing list archive] in case someone has
 already reported and fixed a similar problem.
 
-However you choose to report bugs or get help,
-xref:bugtracker[opening a bug] or
-xref:mailing-list-subscribe[send a mail to the mailing list], there are
+However you choose to report bugs or get help, either by
+xref:bugtracker[opening a bug] or by
+xref:mailing-list-subscribe[sending a mail to the mailing list], there are
 a number of details to provide in order to help people reproduce and
 find a solution to the issue.
 
@@ -295,11 +295,16 @@ Here is a short list of details to provi
 * host machine (OS/release)
 * version of Buildroot
 * target for which the build fails
-* package(s) which the build fails
+* package(s) for which the build fails
 * the command that fails and its output
 * any information you think that may be relevant
 
-Additionnally, your can add the +.config+ file.
+Additionally, you should add the +.config+ file (or if you know how, a
++defconfig+).
 
 If some of these details are too large, do not hesitate to use a
-pastebin service (see http://www.similarsitesearch.com/alternatives-to/pastebin.com[]).
+pastebin service. Note that not all available pastebin services will
+preserve Unix-style line terminators when downloading raw pastes.
+Following pastebin services are known to work correctly:
+- https://gist.github.com/
+- http://code.bulix.org/

[Buildroot] [PATCH 6 of 7] manual: contributing: minor rewording of 'reporting bugs' section

[Samuel Martin]

On Thu, Mar 6, 2014 at 11:07 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> This patch makes some minor fixes in the section about reporting bugs.
>
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Acked-by: Samuel Martin <s.martin49@gmail.com>

>
> ---
> v2: provide an explicit list of 'good' pastebins (Yann)
>
>  docs/manual/contribute.txt |  21 +++++++++++++--------
>  1 files changed, 13 insertions(+), 8 deletions(-)
>
> Although I don't think this section belongs in the Contributing chapter,
> there currently isn't a better place. When I get to rethinking the manual
> structure, this can be changed.
>
> diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
> --- a/docs/manual/contribute.txt
> +++ b/docs/manual/contribute.txt
> @@ -274,16 +274,16 @@ This can be easily handled with +git for
>  ---------------------
>
>  [[reporting-bugs]]
> -Reporting issues/bugs, get help
> --------------------------------
> +Reporting issues/bugs or getting help
> +-------------------------------------
>
>  Before reporting any issue, please check
>  xref:mailing-list-subscribe[the mailing list archive] in case someone has
>  already reported and fixed a similar problem.
>
> -However you choose to report bugs or get help,
> -xref:bugtracker[opening a bug] or
> -xref:mailing-list-subscribe[send a mail to the mailing list], there are
> +However you choose to report bugs or get help, either by
> +xref:bugtracker[opening a bug] or by
> +xref:mailing-list-subscribe[sending a mail to the mailing list], there are
>  a number of details to provide in order to help people reproduce and
>  find a solution to the issue.
>
> @@ -295,11 +295,16 @@ Here is a short list of details to provi
>  * host machine (OS/release)
>  * version of Buildroot
>  * target for which the build fails
> -* package(s) which the build fails
> +* package(s) for which the build fails
>  * the command that fails and its output
>  * any information you think that may be relevant
>
> -Additionnally, your can add the +.config+ file.
> +Additionally, you should add the +.config+ file (or if you know how, a
> ++defconfig+).
>
>  If some of these details are too large, do not hesitate to use a
> -pastebin service (see http://www.similarsitesearch.com/alternatives-to/pastebin.com[]).
> +pastebin service. Note that not all available pastebin services will
> +preserve Unix-style line terminators when downloading raw pastes.
> +Following pastebin services are known to work correctly:
> +- https://gist.github.com/
> +- http://code.bulix.org/
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Regads,

-- 
Samuel

[Buildroot] [PATCH 7 of 7] manual: contributing: modify commit message template

[Thomas De Schampheleire]

This patch updates the commit message template provided in the manual.
The new template emphasizes the importance of providing a description of the
problem, the root cause, and the solution, and the fact that all this should
be wrapped at 72 characters.

Suggested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v2: new patch

 docs/manual/contribute.txt |  15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
--- a/docs/manual/contribute.txt
+++ b/docs/manual/contribute.txt
@@ -244,13 +244,20 @@ be preserved forever in the +git+ histor
 Hereafter the recommended layout:
 
 ---------------
-Patch title less than 80-character length
+Patch title: short explanation, max 72 chars
 
-A paragraph giving more details.
+A paragraph that explains the problem, and how it manifests itself. If
+the problem is complex, it is OK to add more paragraphs. All paragraphs
+should be wrapped at 72 characters.
 
-And yet another paragraph giving more details.
+A paragraph that explains the root cause of the problem. Again, more
+than on paragraph is OK.
 
-Signed-off-by: John Doe <john.doe@noname.org>
+Finally, one or more paragraphs that explain how the problem is solved.
+Don't hesitate to explain complex solutions in detail.
+
+Signed-off-by: John DOE <john.doe@example.net>
+
 ---
 Changes v2 -> v3:
   - foo bar  (suggested by Jane)

[Buildroot] [PATCH 0 of 7] manual: rework Contributing chapter

[Thomas De Schampheleire]

On Thu, Mar 6, 2014 at 11:07 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
>
> This patch series reworks the "Contributing to Buildroot" chapter in the
> manual. According to the latest Buildroot Developer Days, we want to promote
> contributions that are not feature patches, like fixing autobuild failures,
> closing bugs, working on items from the TODO list, etc. This series reorders
> and expands the chapter with that desire in mind.
>
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>
> ---
> v2:
> - integrate rewording comments by Yann, Samuel and Arnout (thanks!)
> - add new patch modifying the commit message template


My apologies of the missing 'v2' in this series subject...

[Buildroot] [PATCH 0 of 7] manual: rework Contributing chapter

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Thu, 06 Mar 2014 11:07:28 +0100, Thomas De Schampheleire wrote:
> 
> This patch series reworks the "Contributing to Buildroot" chapter in the
> manual. According to the latest Buildroot Developer Days, we want to promote
> contributions that are not feature patches, like fixing autobuild failures,
> closing bugs, working on items from the TODO list, etc. This series reorders
> and expands the chapter with that desire in mind.
> 
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Series applied, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com