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, 25 Jul 2016 17:42:09 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Rich Felker <dalias@...c.org>
Cc:	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Marc Zyngier <Marc.Zyngier@....com>
Subject: Re: linux-next: build warning after merge of the tip tree

On Mon, Jul 25, 2016 at 10:53:37AM -0400, Rich Felker wrote:
> On Mon, Jul 25, 2016 at 03:11:48PM +0200, Daniel Lezcano wrote:

> > I don't know the goal of adding those patches in linux-next via your
> > tree, may be you misunderstood how linux-next works and you should
> > remove them. But if the purpose was to merge the patches, I remind you
> > that being an arch maintainer does not give you the right to apply any
> > patches, everywhere, at all cost, without review, because you want them
> > in, you must follow the process, otherwise you take the risk to upset a
> > lot of people and to be kicked out.

> If this is upsetting people I can remove them. Last time I got
> feedback from at least one (driver) subsystem maintainer that (if I
> understood it correctly) indicated they would like to have seen the
> patch in linux-next without problems before upstreaming it through

I think that was me and you've very much misunderstood what I was
saying.  A that time you were sending new drivers during the merge
window with the apparent expectation that they would be merged during
that merge window.  That's not going to happen, things need to go into
-next before the merge window.  This means that you need to submit your
patches well in advance of the merge window so they can be reviewed and
ideally applied to maintainer trees before the merge window opens.

It does not mean that you should include unreviewed code for other trees
in your -next tree, that's not the purpose of -next.  What goes into
-next from each maintainer tree should be what is currently intended to
go to Linus for that tree in the next merge window.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ