All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: Thomas Hellstrom <thellstrom@vmware.com>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Alison Wang <alison.wang@freescale.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Russell King <rmk+kernel@arm.linux.org.uk>,
	Vincent Abriou <vincent.abriou@st.com>
Subject: RFC: DRM trivial tree
Date: Wed, 7 Oct 2015 17:15:56 +0200	[thread overview]
Message-ID: <20151007151556.GA1975@ulmo> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 2520 bytes --]

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.

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.

Thierry

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

             reply	other threads:[~2015-10-07 15:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-07 15:15 Thierry Reding [this message]
2015-10-07 23:04 ` RFC: DRM trivial tree 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

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=20151007151556.GA1975@ulmo \
    --to=thierry.reding@gmail.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=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.