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