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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
