From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
Alison Wang <alison.wang@freescale.com>,
dri-devel@lists.freedesktop.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Russell King <rmk+kernel@arm.linux.org.uk>,
Vincent Abriou <vincent.abriou@st.com>
Subject: Re: RFC: DRM trivial tree
Date: Fri, 9 Oct 2015 22:54:31 +0200 [thread overview]
Message-ID: <20151009225431.6fa1c869@bbrezillon> (raw)
In-Reply-To: <20151007151556.GA1975@ulmo>
Hi Thierry,
On Wed, 7 Oct 2015 17:15:56 +0200
Thierry Reding <thierry.reding@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?
>
> 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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2015-10-09 20:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 15:15 RFC: DRM trivial tree Thierry Reding
2015-10-07 23:04 ` Dave Airlie
2015-10-08 7:46 ` Daniel Vetter
2015-10-08 8:16 ` Thierry Reding
2015-10-08 9:01 ` Vincent ABRIOU
2015-10-08 8:03 ` Thierry Reding
2015-10-09 20:54 ` Boris Brezillon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151009225431.6fa1c869@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=alison.wang@freescale.com \
--cc=benjamin.gaignard@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=thellstrom@vmware.com \
--cc=thierry.reding@gmail.com \
--cc=vincent.abriou@st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox