RFC: late drm pull requests and other topics

[Jani Nikula]

On Tue, 07 Mar 2017, Daniel Vetter <daniel at ffwll.ch> wrote:
> Hi all,
>
> In the 4.11 drm pull request Linus raised a few things that we need to discuss:
>
> Late driver/enabling pull requests
> ----------------------------------
>
> Imo this isn't as one-sided as Linus made it sound, we've had the policy of
> pulling new drivers and enabling for new hw very late in the merge window
> forever. And I think there's some good benefits, both for users as for companies
> trying to do early enabling. It's just that in the past few years it's been
> mostly arm drivers (where Linus doesn't see the inevitable Kconfig fail) or new
> code in existing big drivers (where Kconfig fail tends to not happen if you
> leave backlight code alone ...).
>
> Anyway, Linus has been pretty clear here, not really wiggle room left and
> personally I think this doesn't hurt us that much, it's more on the unfortunate
> side. I discussed this a bit with Dave on irc, and the proposal would be that
> every feature patch must be in linux-next by -rc6 and in drm-next by -rc7. This
> is how drm-intel has run since years, and also what we started doing with
> drm-misc (except new platform enabling, which I guess now can't happen any more,
> amdgpu with Vega will probably be hurt first). So works, just means everyone
> needs to queue stuff early and also have their tree in linux-next (or get into
> drm-misc if that's too much pain).

The sad part is when the shit hits the fan as a result of us being kind
and accepting stuff near the merge window, with the idea that new
drivers and enabling won't regress anything. For everything else the
rule has been -rc5-ish for some time and should remain that way. We'll
just have to document and be transparent about the reasons why we're
being strict.

Spelling out the obvious, the penalty for missing the deadline is a
delay of one kernel release, or about 10 weeks. Folks, please let's keep
that in mind when we're contemplating the bikeshedding review near that
critical time frame. Let's be considerate.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center