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
| ||
|
Message-ID: <94507081.822839.1405948374414.open-xchange@webmail.nmp.skynet.be> 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/
Powered by blists - more mailing lists