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: <20090115105453.GF29296@elte.hu>
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ