linux-kernel - Re: [PATCH] Remove errors caught by checkpatch.pl in kernel/kallsyms.c

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Feb 2009 18:21:47 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Julia Lawall <julia@...u.dk>, Sam Ravnborg <sam@...nborg.org>,
	Manish Katiyar <mkatiyar@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] Remove errors caught by checkpatch.pl in
	kernel/kallsyms.c

* Stefan Richter <stefanr@...6.in-berlin.de> wrote:

> Julia Lawall wrote:
> > Is everything below the --- preserved in what is available via git log?  
> 
> No, none of it (if the patch is mechanically applied with e.g. git-am).
> 
> Sometimes, useful information does indeed get lost because an author
> didn't consider it "above ---"-worthy.
> 
> ...
> > I think the how information has some value, 
> > both to make people aware of what tools are useful for what kinds of 
> > tasks, and to help one understand what criteria were used in making the 
> > patch.
> 
> That information is perfect for conservation mailing list archives.

Uhm, a mailing list archives have numerous well-known disadvantages: 
they are not permanent or accessible in any acceptable fashion - URLs 
can go stale, certain mails get lost, the commit itself has no backlink 
to the lkml discussion [or whichever of the hundreds of maintainer lists 
it was discussed on], etc. etc.

Claiming that information is 'perfect' for the mailing list but not good 
for the Git log is a double standard.

The thing is, we need more information about how a given patch was 
originated, not less. We need more information about how efficient our 
tools are, not less.

The main problems we have with commit logs today is not too much 
information but too little information. A log message should be 
well-structured, with the more important information near the top of it, 
the less important information at the end - but arguing that something 
as fundamental as the tools that motivated a change is silly on its 
face.

	Ingo
--
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/