On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote: > On 8 October 2015 at 01:15, Thierry Reding <thierry.reding@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
