linux-kernel - Re: linux-next: build warning after merge of the tip tree

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160725175434.GU15995@brightrain.aerifal.cx>
Date:	Mon, 25 Jul 2016 13:54:34 -0400
From:	Rich Felker <dalias@...c.org>
To:	Mark Brown <broonie@...nel.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 05:42:09PM +0100, Mark Brown wrote:
> 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.

OK, thanks for the clarification. I'll remove the drivers from my
for-next branch.

Rich