Re: [PATCH] Handle long lines properly

From: Willy Tarreau <w#1wt.eu>
Date: Thu, 1 Nov 2007 13:13:57 +0100

Hi Krzysztof,

On Thu, Nov 01, 2007 at 12:41:53AM +0100, ole#ans.pl wrote:
> >From 9260147f45cb95827045ef83039078b147682322 Mon Sep 17 00:00:00 2001
> From: Krzysztof Piotr Oledzki <ole#ans.pl>
> Date: Thu, 1 Nov 2007 00:33:12 +0100
> Subject: [MEDIUM] Handle long lines properly

I've merged your patch and updated git 1.3.13 with it.

BTW, I'm glad that you formated the subject line like I used to since the beginning. It's very handy when I have to backport fixes to older branches for instance. I think I should document a bit the practises I tend to follow. I generally put one word between brackets to indicate the importance of the patch followed by a short description. The words I generally use are :

MINOR minor fix, very low risk of impact MEDIUM medium risk, may cause unexpected regressions of low importance or

          which may quickly be discovered (just like this patch)
MAJOR     major risk of hidden regression. This happens when I rearrange large
          parts of code, when I play with timeouts, with variable
          initializations, etc...
BUG       fix for a minor or medium-level bug.
CRITICAL  medium-term reliability or security is at risk, an upgrade is
          absolutely required.
RELEASE   release a new version
BUILD     fix build issues. If you could build, no upgrade required.
CLEANUP   code cleanup, silence of warnings, etc... theorically no impact
TESTS     added regression testing configuration files or scripts
DOC       documentation updates, no need to upgrade

LICENSE licensing updates (may impact distro packagers)

I may invent other ones as required, but I generally can classify all the work with these ones. All those indicators are very subjective and may even depend on the time I spend doing the work, hunting a bug or even on my mood. If this works correctly, we should observe most MAJOR/MEDIUM updates between major versions, and mostly MINOR/BUG updates when updating the 4th digit.

I strongly encourage submitters to follow a similar scheme (as you did) since it makes it very easy for everyone to track changes and possibly to update their local branches.

I will probably update a "contrib" file with those indications.

Best regards,
Willy Received on 2007/11/01 13:13