RFC: DRM trivial tree

[Daniel Vetter]

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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch