From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: RFC: DRM trivial tree Date: Wed, 7 Oct 2015 17:15:56 +0200 Message-ID: <20151007151556.GA1975@ulmo> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1399060639==" Return-path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by gabe.freedesktop.org (Postfix) with ESMTPS id 452A46EBC9 for ; Wed, 7 Oct 2015 08:15:59 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so218619816wic.0 for ; Wed, 07 Oct 2015 08:15:57 -0700 (PDT) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org Cc: Thomas Hellstrom , Benjamin Gaignard , Alison Wang , Laurent Pinchart , Russell King , Vincent Abriou List-Id: dri-devel@lists.freedesktop.org --===============1399060639== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWFTcpAAoJEN0jrNd/PrOh1N0QAKHqgVas1TEL96S/GNIXk+cV WDx/F1vYWyMhO4eHM6T9h0XQI4zOpZa0Gig3DbpNkqFBT3WZKAR7PQ8wbHuZHTSm K7DnqKDktdyAkb/Amjjxab5fAhAFiHEuBUem3uT3iqImjePrByOiVm7/Up6buovX 7eSXgY1YY/SMfhNhShMnL9EukNhq/BKzHNdyUKCNKlhZyV7r8bHfpnsJ6ctRPXiD rlE4eW2tl3wNg9KDhQKvl3/Kq48MTgl2Qj6AOW2vQq7Xd/MDzJueajxZko0UHFb3 X/dI5WRyj+cNFr5RntbR0Oos4Fu0gL0a/7JyuCyl14121zqdRLlSo1t4pG5UzzPr feZ1Y0eJwlpmuYwoduCb7auvBNRxsyAqDMRLev85Q+x8UjET5tUVEVdbHxlB26+u +gF4oZY1RoTVCVvQ7mF5Q9ZU5ZAcxKPN3rdQ+bt6ikj2f4hLbnN2NPYgiu/HR/oW kShf0qxKFOBkmgXn7lb+ViluKFnK1bsPT1ken9BOJ8ca/UafOu5WhBynl0HogCUP K/U5XXkNmZUS3mmPateF1DUoD/frZDwAsUlajrOx1IJA5ekfk2CqkY/8oZjBRDAM UhMUYoZVjdX/KIXoM2Tl6jGeXgJhb/Tzm1ebQC0Ln/wvqzcGE0yQhnKdpNi2TQnC bVFHh3zAk8Cg8adgKgGP =A0nw -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- --===============1399060639== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1399060639==--