From patchwork Wed Mar 5 16:24:30 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas De Schampheleire X-Patchwork-Id: 327073 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from hemlock.osuosl.org (hemlock.osuosl.org [140.211.166.133]) by ozlabs.org (Postfix) with ESMTP id 4D3742C00BD for ; Thu, 6 Mar 2014 03:28:54 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id B455595345; Wed, 5 Mar 2014 16:28:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSe+ep1-mMcn; Wed, 5 Mar 2014 16:28:44 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by hemlock.osuosl.org (Postfix) with ESMTP id AC3F59549A; Wed, 5 Mar 2014 16:28:44 +0000 (UTC) X-Original-To: buildroot@lists.busybox.net Delivered-To: buildroot@osuosl.org Received: from silver.osuosl.org (silver.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 5F4241BF95D for ; Wed, 5 Mar 2014 16:28:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 59970331FD for ; Wed, 5 Mar 2014 16:28:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv7VyDurfqlw for ; Wed, 5 Mar 2014 16:28:41 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by silver.osuosl.org (Postfix) with ESMTPS id B6D8D3322E for ; Wed, 5 Mar 2014 16:28:40 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id k10so1155001eaj.40 for ; Wed, 05 Mar 2014 08:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:subject :message-id:in-reply-to:references:user-agent:date:from:to; bh=fU+x7+aGVdWuV30USo82scCj9Zj5BXIlaJP0TAr3j5A=; b=idzweQQctA/ZiE2hMIqC2aKQLqRregwv9ls9z05bM8uY9GCJ/Ab8vGmd40HGQcDBPR a/yixyARgs6zFoe8n+aFvOfaLBlk1aWfqTm76bE+oq6AUOO1TrYjIIzbvkdPzmjyB0Kk pWa/er1QJ9cByG49WKd+G7uPjqQMTEaT83yJBBVOw+EaKEK2wadg2c9FT+FiZEL0pERQ aSbcd6COmiAxVdqxrL80eRBZOfyvJa5Ry8N02dnIcb4M6bSANlMwra7VHmNODGiOi5hq Tj62ty/zLZIlGTG9ObyTYoJchAKa5I9RECjbzFaw1/mk3uNXiUuJuuQan0tFZWJjmFmC Zsvw== X-Received: by 10.14.182.5 with SMTP id n5mr6754039eem.68.1394036919215; Wed, 05 Mar 2014 08:28:39 -0800 (PST) Received: from [127.0.1.1] (d54C62EEB.access.telenet.be. [84.198.46.235]) by mx.google.com with ESMTPSA id 54sm10942999eek.19.2014.03.05.08.28.36 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 08:28:37 -0800 (PST) MIME-Version: 1.0 X-Mercurial-Node: a96a7201cce3dcfda3d55273cb81e13c4cb60f32 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Wed, 05 Mar 2014 17:24:30 +0100 From: Thomas De Schampheleire To: buildroot@buildroot.org Subject: [Buildroot] [PATCH 4 of 8] manual: contributing: move section on patch reviews up and change intro X-BeenThere: buildroot@busybox.net X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion and development of buildroot List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: buildroot-bounces@busybox.net Sender: buildroot-bounces@busybox.net 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 Reviewed-by: "Yann E. MORIN" --- 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 @@ -75,6 +75,71 @@ 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 in judging which patches are ready to +apply and which aren't. Contributors can greatly help here by reviewing +and testing these patches, and providing the appropriate Tested-by, +Reviewed-by, or Acked-by tags (see below). + +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. + + [[submitting-patches]] Submitting patches ------------------ @@ -190,68 +255,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 -------------------------------