[GIT PULL v2 1/2] ARM: tegra: Core code changes for v4.1-rc1

[Thierry Reding]

On Tue, Apr 14, 2015 at 10:30:30AM +0200, Arnd Bergmann wrote:
> On Tuesday 14 April 2015 09:06:50 Thierry Reding wrote:
> > On Tue, Apr 14, 2015 at 01:09:56AM +0200, Arnd Bergmann wrote:
> > > On Saturday 11 April 2015, Michael Turquette wrote:
> > > > > Tomeu Vizoso (8):
> > > > >       of: Document long-ram-code property in nvidia,tegra20-apbmisc
> > > > >       of: Document timings subnode of nvidia,tegra-mc
> > > > >       memory: tegra: Disable ARBITRATION_EMEM interrupt
> > > > >       of: document new emc-timings subnode in nvidia,tegra124-car
> > > > >       of: document external-memory-controller property in tegra124-car
> > > > >       clk: Expose clk_hw_reparent() to providers
> > > > 
> > > > ... this patch! I'd prefer to not do this. Let's see if
> > > > .set_rate_and_parent solve the problem for you.
> > > 
> > > Not pulling this for 4.1 then. Even without the objections, it was basically
> > > too late for the amount of changes now.
> > 
> > For my education, when do you expect pull requests with "this amount of
> > changes" to be sent?
> 
> Generally speaking, we want large patch series to come early after -rc1,
> followed by smaller subsequent updates. We often don't get around to
> applying stuff before -rc3, which is a problem on our side, but it helps
> to have patches available by then.
> 
> Also, if you have a large series (100+ patches) early on, we'd be more
> likely to take a 20-patch series later than if the 20-patch series comes
> at rc6 and is the first thing we see from you: after around rc5 or rc6,
> what we want to see are mostly patches that directly result from work
> that we merged earlier for the same merge window, like regression fixes
> or wrapping up a larger series that was started but incomplete at -rc2.

That's not generally what we've done on Tegra. We usually keep things in
linux-next until around -rc6 to make sure whatever gets pulled into the
arm-soc tree is stable.

With what you said above I'm pretty much forced to either send you pulls
that aren't well tested (linux-next isn't supposed to get new code until
after -rc1) or I have to plan for an extra release cycle for anything
that is "big", which would mean that many new features would potentially
take 6 months to get merged.

I don't like either of those choices.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150414/21677873/attachment-0001.sig>