From patchwork Sun Sep 13 17:02:38 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Blue Swirl X-Patchwork-Id: 33552 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bilbo.ozlabs.org (Postfix) with ESMTPS id 82105B6F34 for ; Mon, 14 Sep 2009 03:03:40 +1000 (EST) Received: from localhost ([127.0.0.1]:37214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmsUC-0003HI-Ti for incoming@patchwork.ozlabs.org; Sun, 13 Sep 2009 13:03:36 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MmsTg-0003H3-AG for qemu-devel@nongnu.org; Sun, 13 Sep 2009 13:03:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MmsTb-0003GW-NV for qemu-devel@nongnu.org; Sun, 13 Sep 2009 13:03:03 -0400 Received: from [199.232.76.173] (port=53113 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmsTb-0003GT-I1 for qemu-devel@nongnu.org; Sun, 13 Sep 2009 13:02:59 -0400 Received: from mail-ew0-f221.google.com ([209.85.219.221]:33202) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MmsTa-0002Qb-V1 for qemu-devel@nongnu.org; Sun, 13 Sep 2009 13:02:59 -0400 Received: by ewy21 with SMTP id 21so2222674ewy.8 for ; Sun, 13 Sep 2009 10:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=9ODUr9lUWcv6TN7I26aLQhQbWK5iSDaVT7WuAsRkJMQ=; b=JkvQRv050Uj4rx1UaxVHxw3WOu7famF+BHTTMVfDsOY5OGjw9cx39hiu+NfQOlqi4y Tptj9IzHnVM5vMwSeF4+67xOF1OfbnPtP2i4VX5bJK6Iw8M4QbD+cVz2gXSSDitk7jbJ a1NXRWXj1ouaVxawUI3QPtM0Ppbv7MFKk+Tqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=xkfj8SaPE8d5g5btY5dvYHmfP0Om7NnUz73c2mjb6d8WGh/s4baTsdSRLukK72Eb8T HnzU9MhSqflZoNbfHaP7Lqk0uJXU5W7zV9mO0+EioBtQ/nbteh8+bIrrht/dJAkJJo9F mKQfH4soMxSAiNguoziz3NZ1ZiUw93aMx2ym4= MIME-Version: 1.0 Received: by 10.211.161.18 with SMTP id n18mr5886616ebo.26.1252861378156; Sun, 13 Sep 2009 10:02:58 -0700 (PDT) From: Blue Swirl Date: Sun, 13 Sep 2009 20:02:38 +0300 Message-ID: To: qemu-devel X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: [Qemu-devel] [PATCH, RFC] Add SUBMITTING_PATCHES X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Problem: Patches are submitted in a way that causes burden for the committer. Solution: Inform patch submitters about more helpful way. Signed-off-by: Blue Swirl --- Changes since previous version: * Removed SoB exception for small patches * Removed quilt from list of applying tools * Added SP7.2 SUBMITTING_PATCHES | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 115 insertions(+), 0 deletions(-) create mode 100644 SUBMITTING_PATCHES diff --git a/SUBMITTING_PATCHES b/SUBMITTING_PATCHES new file mode 100644 index 0000000..10f6db7 --- /dev/null +++ b/SUBMITTING_PATCHES @@ -0,0 +1,115 @@ +Whereas the QEMU developers highly appreciate any patches, it would be +most helpful for all parties if the following rules were followed in +order to simplify mechanical extraction and applying of the +patches. Patch management utilities (git send-email, quilt, and +similar) can assist in producing compatible patches and patch sets +with correct formatting etc., so their use is recommended. + +1. Format of e-mail subject + +SP1.1: The e-mail subject must contain "PATCH" in brackets, followed +by white space and a short summary of the change. + +SP1.2: The bracketed text may also include other commonly used tags +separated with a comma and white space, including "RFC" (Request for +Comments, for patches submitted for discussion and review purposes +only) and "RFT" (Request for Testing, for patches which are suspected +to introduce problems in use cases which have not been tested by the +submitter). + +SP1.3: The summary must be suitable for changelog as is (start with a +capital letter etc.) after deleting the bracketed text, white space +after it and any text preceding it. + +2. Format of e-mail body + +SP2.1: The e-mail body must contain a description of the change, +suitable for changelog without any editing. + +SP2.2: The patch description must be selfstanding (not depend on other +patches, other messages or background discussion). + +SP2.3: The description must be followed by one blank line and a +"Signed-off-by:" line. + +SP2.4: Optionally, the "Signed-off-by:" line may be followed with a +line with only "---" and on the following lines, other comments not +intended for changelog (for example diffstat, location of a git tree, +whether the patch is also directed towards stable tree, witty +signature etc.). + +SP2.5: Exception: The rules in this section are not applicable for +patches tagged with "RFC" or "RFT" + +3. Attaching patches to e-mail + +SP3.1: Each message may contain only one patch + +SP3.2: If possible, please send the patch inlined (to make commenting +easier) and also attached (to make it easier to apply) + +SP3.2: If the patch is attached (and not inlined) it should be marked +as text/plain content type + +SP3.3: Please ensure in advance that your e-mail tool does not mangle +white space or break long lines + +4. About patches + +SP4.1: It must be possible to apply the patch with "git am" without +any editing or extra flags (git config apply.whitespace=fix). + +SP4.2: The patch must be based in the QEMU root directory (not for +example KVM, Xen or lower level subdirectory) + +SP4.3: The patches targeted for development branch must be based on +the current development repository. + +SP4.4: The patches targeted for stable branch must be based on the +current stable repository. + +5. Changes made by the patch + +SP5.1: Do not combine formatting changes with functional changes. + +SP5.2: Do not combine several independent functional changes to one +patch unless required by the logic of the changes. + +SP5.3: The changes may not introduce new violations of CODING_STYLE. + +SP5.4: If the changes involve new or changed user interface, +documentation and help messages must be changed as well. + +SP5.5: If the changes add new files, make sure that the patch includes +them (for example, use diff flag -N). + +SP5.6 Please check that the changes do not introduce new warnings to +be emitted when compiling the sources, preferably not even when +compiling with Sparse checker. + +6. Series of patches + +SP6.1 Patch series should be numbered with the number included inside +the brackets in the subject (for example "[PATCH 09/17]"). + +SP6.2: The patch series should include a cover letter describing the +patchset in general (as opposed to individual patch descriptions). + +SP6.3: No changes in a single patch in the patch series may break the +ability to bisect (make sure that when applying the patches +sequentially step by step, working executables can be produced at each +step and not only at the final step). + + +7. Legal aspects + +SP7.1: Any new files or merges from other sources must be licenced +with licences compatible with QEMU licencing (for example, GPLv3 or +CDDL are not compatible). + +SP7.2: Any new files must mention its licence unless it is technically +impossible. + +SP7.3: The "Signed-off-by:" line is a form of legal declaration which +the submitter must be aware of (please see Linux +Documentation/SubmittingPatches).