RFC: late drm pull requests and other topics

Tue Mar 7 20:45:48 UTC 2017

On Tue, Mar 7, 2017 at 10:56 AM, Alex Deucher <alexdeucher at gmail.com> wrote:
> 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.

I discussed this a bit with Daniel on IRC and I realized I may not
have made myself clear.  My main point was that I think it's important
not to shield our developers too much.  They need to have some
knowledge or linux-kernel and other subsystems just to get a taste of
different development styles or things that might not have occurred to
them so seeing feedback from outside developers is important.  I'm not
condoning threats or insults.

Alex

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