All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.