linux-kernel - Re: [PULL -tip] fixed few make headers

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:	Thu, 15 Jan 2009 11:54:53 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Jaswinder Singh Rajput <jaswinder@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PULL -tip] fixed few make headers_check warnings


* Sam Ravnborg <sam@...nborg.org> wrote:

> On Tue, Jan 13, 2009 at 01:49:21PM +0100, Ingo Molnar wrote:
> > 
> > * Jaswinder Singh Rajput <jaswinder@...radead.org> wrote:
> > 
> > > Hello Ingo,
> > > 
> > > Please pull these patches. Earlier I also floated these patches so that 
> > > I can get some feedback.
> > 
> > Sam, Andrew, David, what's your workflow preference for these bits?
> > 
> > While they are oneliners and i could create a separate branch for these 
> > and pull Jaswinder's tree (and do build coverage to make sure there's no 
> > surprised on any arch), it's really up to the maintainers of these files 
> > to decide on the workflow.
> > 
> > I'd lean towards doing this via the individual maintainers and/or -mm, but 
> > no strong feelings ...
> 
> As they are one-liners for the most part I am fine with you handling
> them in a eparate branch.
> 
> It is far better than I queue them up for at least two weeks before I
> can give the kernel a bit of attention again.
> 
> Obviously it would be better if the Maintainers took them but history 
> tells us we cannot rely on that for all areas.

i dont think maintainers are bad at doing this - the problem and overhead 
is on the submission side: the logistics of spreading dozens of very small 
commits out to dozens of maintainers - each of who prefers a different 
submission channel.

We have no automation for that (to make sure there's guaranteed progress 
and to make sure there's no lost patch) and hence it's simply neither 
efficient nor reliable to do it.

These particular commits seem rather uncontroversial - and they are not 
part of some bigger facility so they are individually revertable as well. 
Worst-case they break the build somewhere or cause a raised maintainer 
eyebrow - we'll try to make sure that no such thing happens on a larger 
scale.

	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/