Re: RFC: DRM trivial tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Thierry,

On Wed, 7 Oct 2015 17:15:56 +0200
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?
> 
> Again, I'm not volunteering to be a maintainer for all of the smaller
> drivers. The goal here is to make it easier to get cleanup patches into
> linux-next, or provide a place where subsystem-wide changes can be
> coordinated. Driver maintainers should still review the patches and in
> many cases I'd want to wait for Acked-by or Reviewed-by tags before
> taking any patches into the trivial tree. Also, while I'll try to
> monitor the list as best I can, it will inevitably happen that I'll miss
> patches. When that happens, feel free to Cc me if you think the patches
> match the above criteria.

I'm perfectly fine with that (even if the question was not directly
asked to me :-)), except that in the tree you made, I see one patch [1]
that is directly related to the atmel-hlcdc driver and not a
transversal cleanup patch (though I don't have any problem letting you
take that patch).

> 
> For a while now it's also been difficult to find maintainers for drivers
> so I'd like to see more entries being added to MAINTAINERS to help
> identify the people that need to be involved and hopefully make this
> process easier.

Just sent a patch adding my name for the atmel-hlcdc driver.

Best Regards,

Boris

[1]http://cgit.freedesktop.org/tegra/linux/commit/?h=drm/trivial/for-next&id=52689f943fb46f560a2277c03debfe79110d0d1f

> 
> Thierry
> 
> [0]: http://cgit.freedesktop.org/tegra/linux/log/?h=drm/trivial/for-next



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux