RFC: late drm pull requests and other topics

[Alex Deucher]

On Mon, Mar 6, 2017 at 7:11 PM, 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).

I've always tried to have all major new features sent to Dave by rc5,
so no problems with the timelines.  Dave and Linus have generally been
ok with new asic support at strange times assuming it has minimal
impact on existing support.  Our code release dates rarely line up
well with kernel cycles, but we can manage.


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

It sucks, but I guess my skin has hardened over the years.  We've had
a fair share of heated arguments even on dri-devel.

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

I agree.  I don't see the need to split up the pulls.  I think we do
pretty well overall.

Alex


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