net/haproxy/patches/0006-DOC-update-CONTRIBUTING-regarding-optional-parts-and.patch

   1 From 20850d19250eb530cab889bb9059a630b3f805a3 Mon Sep 17 00:00:00 2001
   2 From: Willy Tarreau <w@1wt.eu>
   3 Date: Tue, 18 Jul 2017 06:56:40 +0200
   4 Subject: [PATCH 06/18] DOC: update CONTRIBUTING regarding optional parts and
   5  message format
   6
   7 Make it clear that optional components must not break when disabled,
   8 that openssl is the only officially supported library and its support
   9 must not be broken, and that bug fixes must always be detailed.
  10 (cherry picked from commit 9d84cd602f4adb3954209eb14c94eea9254d1b5b)
  11
  12 Signed-off-by: Willy Tarreau <w@1wt.eu>
  13 ---
  14  CONTRIBUTING | 21 ++++++++++++++++++++-
  15  1 file changed, 20 insertions(+), 1 deletion(-)
  16
  17 diff --git a/CONTRIBUTING b/CONTRIBUTING
  18 index 74a099bc..b2c2b493 100644
  19 --- a/CONTRIBUTING
  20 +++ b/CONTRIBUTING
  21 @@ -69,6 +69,16 @@ code :
  22  Since most of these restrictions are just a matter of coding style, it is
  23  normally not a problem to comply.
  24
  25 +When modifying some optional subsystem (SSL, Lua, compression, device detection
  26 +engines), please make sure the code continues to build (and to work) when these
  27 +features are disabled. Similarly, when modifying the SSL stack, please always
  28 +ensure that supported OpenSSL versions continue to build and to work, especially
  29 +if you modify support for alternate libraries. Clean support for the legacy
  30 +OpenSSL libraries is mandatory, support for its derivatives is a bonus and may
  31 +occasionally break eventhough a great care is taken. In other words, if you
  32 +provide a patch for OpenSSL you don't need to test its derivatives, but if you
  33 +provide a patch for a derivative you also need to test with OpenSSL.
  34 +
  35  If your work is very confidential and you can't publicly discuss it, you can
  36  also mail willy@haproxy.org directly about it, but your mail may be waiting
  37  several days in the queue before you get a response, if you get a response at
  38 @@ -441,13 +451,22 @@ do not think about them anymore after a few patches.
  39     way the subject is built. Please see the section below for more information
  40     regarding this formatting.
  41
  42 -   As a rule of thumb, your patch must never be made only of a subject line,
  43 +   As a rule of thumb, your patch MUST NEVER be made only of a subject line,
  44     it *must* contain a description. Even one or two lines, or indicating
  45     whether a backport is desired or not. It turns out that single-line commits
  46     are so rare in the Git world that they require special manual (hence
  47     painful) handling when they are backported, and at least for this reason
  48     it's important to keep this in mind.
  49
  50 +   Each patch fixing a bug MUST be tagged with "BUG", a severity level, an
  51 +   indication of the affected subsystem and a brief description of the nature
  52 +   of the issue in the subject line, and a detailed analysis in the message
  53 +   body. The explanation of the user-visible impact and the need for
  54 +   backporting to stable branches or not are MANDATORY. Bug fixes with no
  55 +   indication will simply be rejected as they are very likely to cause more
  56 +   harm when nobody is able to tell whether or not the patch needs to be
  57 +   backported or can be reverted in case of regression.
  58 +
  59  12) Discuss on the mailing list
  60
  61     When submitting changes, please always CC the mailing list address so that
  62 --
  63 2.13.0
  64