linux-kernel - Re: [bug] build failure in net/netfilter/nf_conntrack

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: <20080419103942.GA13599@elte.hu>
Date:	Sat, 19 Apr 2008 12:39:42 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Miller <davem@...emloft.net>
Cc:	linux-kernel@...r.kernel.org, kaber@...sh.net,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org
Subject: Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on
	latest -git

* David Miller <davem@...emloft.net> wrote:

> From: Ingo Molnar <mingo@...e.hu>
> Date: Sat, 19 Apr 2008 12:00:35 +0200
> 
> > btw., i found no thread to reply to on lkml or elsewhere - arent all 
> > git pull requests supposed to be Cc:-ed to lkml, with shortlog 
> > included?
> 
> I have never once done this even going all the way back to the BK 
> days.

do you find this practice of private pull requests important? If not, 
would it be difficult to Cc: lkml to routine pull requests?

> I always send my pull requests directly to Linus, CC:'ing Andrew.

that makes bugs harder to report and makes the flow of patches harder to 
follow as well. Often (like in this case) i see it when a bug comes in 
via a specific group of commits but i have no time to do a bisection. In 
that case i'd like to report it to that pull request so i'd like to 
reply to that pull on lkml.

But in this case i first did an unsuccessful full-text search on lkml, 
then i also opened up netdev and did a full text search there too to 
find the originator pull request or the patches but the search turned up 
nothing. As the number of subsystems increases, i suspect you agree with 
me that this does not scale very well for bug reporters, correct?

i'm convinced that testers and bug reporters are the scarce resource 
these days, not patch integrators and not maintainers which was the 
scarce resource 3-4 years ago, before Git and before BK. It is testing 
(and review) capacity that limits the growth of Linux today, not patch 
writing and patch integration capacity.

	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/