netdev - Re: [PATCH] net/sunrpc/xprtsock.c: some common code found

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]

Message-Id: <1234027321.17241.25.camel@heimdal.trondhjem.org>
Date:	Sat, 07 Feb 2009 12:22:01 -0500
From:	Trond Myklebust <Trond.Myklebust@...app.com>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:	David Miller <davem@...emloft.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	chuck.lever@...cle.com, bfields@...ldses.org, trond@...app.com,
	linux-nfs@...r.kernel.org, Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] net/sunrpc/xprtsock.c: some common code found

On Sat, 2009-02-07 at 18:56 +0200, Ilpo Järvinen wrote:
> Can you please tell if you're still under impression that there wasn't
> any changelog? What about those other guys who raised their concerns?
> (I can certainly understand why this impression might develop but it's a 
> problem in the canonial patch format, not in my actual changelog, I even 
> need to circumvent ^--- by adding a space the to prevent tools for making 
> a mistake). It will make a lot more sense after getting applied.
> ...Because there certainly was a changelog, and I didn't have any 
> diffstat output there in the changelog?!? The output that *is* in the 
> changelog is supposed to *help* the reviewer to see what will be still 
> necessary to keep in the separate functions, but I guess people missed 
> that because the changelog looks too similar to what you will categorize 
> as patch (diff-funcs uses output which is familiar to all who who deal 
> with patches, and that's for purpose!).

If Chuck and Bruce are happy with it, then there is no problem, however
I have yet to see an acked-by from either one of them. My point is that
the process for accepting patches into the kernel involves ensuring that
there is consensus. It does not allow for one group to ride roughshod
over the objections of another.

   Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html