RFC: DRM trivial tree

[Vincent ABRIOU]

On 10/08/2015 10:16 AM, Thierry Reding wrote:
> On Thu, Oct 08, 2015 at 09:46:50AM +0200, Daniel Vetter wrote:
>> On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote:
>>> On 8 October 2015 at 01:15, Thierry Reding <thierry.reding at gmail.com> wrote:
>>>> Hi everyone,
>>>>
>>>> Lately I've noticed that a bunch of trivial patches have been posted
>>>> across all drivers. We've also encountered situations in the past where
>>>> (relatively trivial) subsystem-wide changes have been made but it ended
>>>> up being very difficult to get patches merged (often because they had
>>>> inter-dependencies and nobody felt responsible for merging them). Often
>>>> Dave has been the last resort for this kind of patches. A side-effect
>>>> has been that it often takes a lot of time for such patches to get
>>>> merged (if at all) and they usually don't end up in linux-next and
>>>> therefore see little testing before they are applied.
>>>>
>>>> To remedy that situation I'd like to propose the addition of a tree to
>>>> keep track of these kinds of patches. Note that the target here are
>>>> trivial patches, such as coding style fixes, fixes for build warnings
>>>> or errors, subsystem-wide API changes, etc. It also targets mostly the
>>>> drivers that don't have a branch that feeds into linux-next. Patches
>>>> against drivers that already feed into linux-next should go through the
>>>> corresponding trees. One reasonable exception for this, in my opinion,
>>>> are subsystem-wide changes, because applying them via different trees
>>>> usually ends up being messy.
>>>>
>>>> I pushed a branch[0] with a set of patches that I've picked up from
>>>> patchwork and which seemed to match the above criteria. I've also Cc'ed
>>>> a bunch of people (mostly a subset of what get_maintainer.pl reported
>>>> for the patches in the branch).
>>>>
>>>> Before going any further with this I'd like to get some feedback on the
>>>> idea. Dave, do you think this is a good idea and would you be willing to
>>>> give this a try?
>>>
>>> I'm not going to object, I'm not sure trivial covers a lot of these
>>> patches though.
>>>
>>> I generally don't go nuts picking up the trivial patches on a weekly basis, as I
>>> don't think they generally need that much attention, a number of the things
>>> in your tree for example are things I've merged into -fixes instead, or I'm
>>> waiting to see if driver maintainers pick them up themselves.
>>>
>>> It would be nice if more driver maintainers had trees feeding into drm-next
>>> or sent me drm-next pull requests no matter how small on a more regular basis
>>> esp after -rc2/3.
>>>
>>> So I probably wouldn't to a pull req from that tree, but it might be something
>>> I'd cherry-pick from if I remember instead of using patchwork.
>>>
>>> At least in theory I'm the last line of maintainer for the non-ARM drivers
>>> (i.e. qxl, mgag200, etc), I don't really want to be last person in line for SoC
>>> drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty
>>> much at the stage where only pull requests from someone who cares will generally
>>> make me merge patches.
>>>
>>> but hey lets give this a go and see if it helps, if you have the time!
>>
>> I think this tree could be useful as a welcoming ground for new folks who
>> send in small fixes as their first patch. I think we have a few of those
>> nowadays (besides the usual tree-wide style police), and I think making
>> sure that their patches get an "ack, merged it to $branch" quickly would
>> help a lot in motivating them to dig in more. So not about patches getting
>> lost, but getting a quick thanks out there. I'm doing that for the core
>> with drm-misc, but there's definitely a gap with armsoc infrastructure and
>> random drivers.
>>
>> So maybe don't call it drm-trivial (since "hey your patch here is trivial"
>> doesn't sound that awesome) but drm-misc-drivers.
>
> I'm afraid that this is going to encourage people to not properly
> maintain their drivers. The reason why I wanted to call it trivial was
> because the requirement would have to be that the patches should be
> small. I lack the knowledge about most SoC drivers to properly review
> patches that go beyond minor things like cleanup.
>

My young maintainer experience make me ask this question:
How maintainer can deal with some patch set that impacts many other 
drivers?

And I think "drm-trivial" (or whatever the name) branch can answer the 
question.

Indeed, it is dangerous to only pick the patch useful for their own 
driver and make a pull request (coherency is not insure). It will 
definitely lead to merge issue if same patches are in different tree.

I understand the need of such "drm-trivial" but I wonder how patch set 
with impacts on different drivers were manage before this proposal?

Vincent


> That said, I guess it would be okay to pick up more complex patches if
> they had an Acked-by or Reviewed-by from a maintainer. Then again, if
> they already find the time to review patches it probably wouldn't be a
> lot more effort to apply them to their own tree.
>
> But that's all really speculation, so perhaps it'd be best to just try
> it out and see how it goes. If it isn't useful we can always drop it
> again.
>
> Thierry
>