RFC: late drm pull requests and other topics

[Daniel Vetter]

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).

Linus shitting on dri-devel
---------------------------

I'm not happy with that, and asked Linus to at least drop dri-devel when he
shits on Dave and maintainers. Dave also brought up the idea of bcc'ing
dri-devel, which should prevent shouting from Linus reliably. Note I'm not
suggesting we ignore Linus' input, just that we keep the 90% insults that it's
wrapped in out of our community as much as we can. Better ideas than bcc would
be good.

Splitting the drm pull
----------------------

I don't think this would be a good idea at all:

- Personally I don't want to send pull requests to Linus. Dave seems ok with
  taking the heat for us, and I'm very happy he's willing to do that. I'd
  certainly not do that.

- There's the small problem that more trees means we need to spent more time
  with the burocratics. From my experience with drm-misc and drm-intel alone
  there's lots of coordination needed, and we resync every 1-3 weeks in drm-next
  with pull requests to Dave. I don't see anyone volunteering to spend more time
  on burocratics, there's already enough to do.

- We've done some really impressive refactorings in drm the past 1-2 years, very
  often cleanups that new driver contributors have done. Looking at drm-misc we
  need to resync about once per month to be able to move forward, since new
  drivers depend upon new refactorings and new refactorings later then need to
  have a tree with all the drivers. So really no way to split things up I think
  without slowing down a lot. And ime if you want to ship upstream as product in
  the embedded space, we're still not fast enough.

  For Intel that'd mean we'd have to pull out a lot of our efforts spent in
  improving the core and helpers, and I think the same holds for a lot of other
  drivers. Many might even entirely drop upstream because bikeshedding a helper
  for 3 months first and then the driver for another 3 months for something
  trivial is silly.

So overall I think overall this would hurt way too much, and we don't have the
people with free time to implement it anyway. Well, without slowing down and
making upstream gfx irrevelant again now that it's finally being taken more
serious. I also discussed this with Dave and others on irc a bit, and Dave
thinks that there shouldn't be any problem for us if we keept he one single
overall subsystem tree.

Those 3 items where the ones I noted, anything I missed?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch