RFC: late drm pull requests and other topics

[Sean Paul]

On Tue, Mar 07, 2017 at 01:11:43AM +0100, Daniel Vetter 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).
> 
> 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.

Pretty much copypasta from irc:

I'm not sure bcc really solves the problem, you'll notice that Linus directly cc'd
the contributor in his rant. Aside from that, his rants usually create a bit of
"omg look at what Linus said" buzz that is sure to get back to contributors. IMO,
the best approach is to do exactly what danvet did last time: praise the contributor
for their work and reiterate the list rule that one must be respectful on dri-devel.
I think everyone agrees that beyond the legitimate concerns about late pulls, the
rest is a non-event and we'll all move on.


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

Yeah, I feel like if we split things up, Linus would likely be even more
unhappy. Even with very careful planning, the drm core changes so frequently
that things are bound to drift. drm-misc does a good job of mostly solving that
issue, and having Dave between the subtree chaos and Linus is very valuable.

Sean

> - 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
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS