linux-kernel - Re: Patch priority in subjects ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 21 Jul 2014 15:12:54 +0200 (CEST)
From:	Fabian Frederick <fabf@...net.be>
To:	Richard Weinberger <richard.weinberger@...il.com>,
	Joe Perches <joe@...ches.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Patch priority in subjects ?



> On 21 July 2014 at 13:33 Richard Weinberger <richard.weinberger@...il.com>
> wrote:
>
>
> On Sun, Jul 20, 2014 at 7:36 PM, Joe Perches <joe@...ches.com> wrote:
> > On Sun, 2014-07-20 at 19:13 +0200, Fabian Frederick wrote:
> >> I was reading all those "friendly" messages around checkpatch -f lately
> >> and the fact that code clean-up is too noisy (?)
> >>
> >> I guess I'm not the first to think about it but why don't we use something
> >> like a priority field in patch subject ?
>
> Code clean up is not bad per se.
> Actually cleaning up things is very much welcome.
>
> The thing is that pure white space or search&replace patches
> produced by checkpatch.pl are often not helpful at all.
> They pollute the git history, introduce merge conflicts, add
> maintenance overhead, etc..
>
> As somebody who regularly stares at code to find outhow the heck
> some line of code got introduced these patches become a major PITA.
> Running commands like are needed far too often:
> git blame ~1 foo/bar.c
>

I understand your point of view now.
Maybe Joe has an idea about this (get_maintainer ...) ?

> Btw: Don't even try to tell me about the -w switch...
>
> >> Of course it would be arbitrary but maybe better than nothing ?
> >>
> >> eg
> >>
> >> [PATCH 1/1 0] Urgent bug fix
> >> [PATCH 1/1 1] Bug fix
> >> [PATCH 1/1 2] ...
> >> [PATCH 1/1 7] kernel-doc fix
> >> [PATCH 1/1 8] Code clean-up
> >> [PATCH 1/1 9] Trivial fix
> >>
> >> Maybe this could help some people to sort/filter/delete
>
> No need to add more bureaucracy, such filtering can perfectly done
> by looking at the sender name. (Sadly...)
> We also have the trivial tree.

I've made a small RFC script so we'll be able to talk around something concrete.
I know it would add some rules to follow but having such a script related in
SubmittingPatches
could help in the following:

-Patch prefix could help making statistics.
-Having automatically -s flag (+others?) avoid thousand of replies "Please add
Signed-off-by".
-Avoid different formats like [PATCH 1 V3] , [PATCH 1/1 v3], [PATCH V3]
-Batch patch generation, checking, sending.
-...

Regards,
Fabian
>
> --
> Thanks,
> //richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/