RFC: late drm pull requests and other topics

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

Re: 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: late drm pull requests and other topics

[Alex Deucher]

On Mon, Mar 6, 2017 at 7:11 PM, Daniel Vetter <daniel@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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: late drm pull requests and other topics

[Jani Nikula]

On Tue, 07 Mar 2017, Daniel Vetter <daniel@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: late drm pull requests and other topics

[Jani Nikula]

On Tue, 07 Mar 2017, Sean Paul <seanpaul@chromium.org> wrote:
> On Tue, Mar 07, 2017 at 01:11:43AM +0100, Daniel Vetter wrote:
>> Linus shitting on dri-devel
>> ---------------------------
>> 
> 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.

Agreed, I prefer this over Bcc.

>> Splitting the drm pull
>> ----------------------
>> 
> 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.

Agreed.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: late drm pull requests and other topics

[Lukas Wunner]

On Tue, Mar 07, 2017 at 10:56:49AM -0500, Alex Deucher wrote:
> On Mon, Mar 6, 2017 at 7:11 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> 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.

Well, you were also once the target of a rant because of too recent
commit dates that turned out to have an entirely innocuous explanation:

https://www.spinics.net/lists/dri-devel/msg87996.html

In a follow-up, Linus said "I want to at least be able to fool myself
into thinking that downstream has really worked hard at validating what
they send me".

https://www.spinics.net/lists/dri-devel/msg87999.html

So since he was asking for it, maybe use something like:

GIT_AUTHOR_DATE=`date --date="8 weeks ago"` \
GIT_COMMITTER_DATE=`date --date="4 weeks ago"` \
  git commit --amend --date

Best regards ;-)

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: late drm pull requests and other topics

[Alex Deucher]

On Tue, Mar 7, 2017 at 10:56 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Mon, Mar 6, 2017 at 7:11 PM, Daniel Vetter <daniel@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@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel