From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: RFC: DRM trivial tree Date: Thu, 8 Oct 2015 10:16:54 +0200 Message-ID: <20151008081654.GB3820@ulmo> References: <20151007151556.GA1975@ulmo> <20151008074650.GX3383@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1513275428==" Return-path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by gabe.freedesktop.org (Postfix) with ESMTPS id B13C26E70F for ; Thu, 8 Oct 2015 01:16:57 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so14041799wic.1 for ; Thu, 08 Oct 2015 01:16:56 -0700 (PDT) In-Reply-To: <20151008074650.GX3383@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: Thomas Hellstrom , Alison Wang , Vincent Abriou , dri-devel , Laurent Pinchart , Benjamin Gaignard , Russell King List-Id: dri-devel@lists.freedesktop.org --===============1513275428== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline --5I6of5zJg18YgZEa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 08, 2015 at 09:46:50AM +0200, Daniel Vetter wrote: > On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote: > > On 8 October 2015 at 01:15, Thierry Reding w= rote: > > > 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 whe= re > > > (relatively trivial) subsystem-wide changes have been made but it end= ed > > > up being very difficult to get patches merged (often because they had > > > inter-dependencies and nobody felt responsible for merging them). Oft= en > > > 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 t= he > > > 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 t= he > > > idea. Dave, do you think this is a good idea and would you be willing= to > > > give this a try? > >=20 > > I'm not going to object, I'm not sure trivial covers a lot of these > > patches though. > >=20 > > I generally don't go nuts picking up the trivial patches on a weekly ba= sis, as I > > don't think they generally need that much attention, a number of the th= ings > > in your tree for example are things I've merged into -fixes instead, or= I'm > > waiting to see if driver maintainers pick them up themselves. > >=20 > > It would be nice if more driver maintainers had trees feeding into drm-= next > > or sent me drm-next pull requests no matter how small on a more regular= basis > > esp after -rc2/3. > >=20 > > So I probably wouldn't to a pull req from that tree, but it might be so= mething > > I'd cherry-pick from if I remember instead of using patchwork. > >=20 > > At least in theory I'm the last line of maintainer for the non-ARM driv= ers > > (i.e. qxl, mgag200, etc), I don't really want to be last person in line= for SoC > > drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty > > much at the stage where only pull requests from someone who cares will = generally > > make me merge patches. > >=20 > > but hey lets give this a go and see if it helps, if you have the time! >=20 > I think this tree could be useful as a welcoming ground for new folks who > send in small fixes as their first patch. I think we have a few of those > nowadays (besides the usual tree-wide style police), and I think making > sure that their patches get an "ack, merged it to $branch" quickly would > help a lot in motivating them to dig in more. So not about patches getting > lost, but getting a quick thanks out there. I'm doing that for the core > with drm-misc, but there's definitely a gap with armsoc infrastructure and > random drivers. >=20 > So maybe don't call it drm-trivial (since "hey your patch here is trivial" > doesn't sound that awesome) but drm-misc-drivers. I'm afraid that this is going to encourage people to not properly maintain their drivers. The reason why I wanted to call it trivial was because the requirement would have to be that the patches should be small. I lack the knowledge about most SoC drivers to properly review patches that go beyond minor things like cleanup. That said, I guess it would be okay to pick up more complex patches if they had an Acked-by or Reviewed-by from a maintainer. Then again, if they already find the time to review patches it probably wouldn't be a lot more effort to apply them to their own tree. But that's all really speculation, so perhaps it'd be best to just try it out and see how it goes. If it isn't useful we can always drop it again. Thierry --5I6of5zJg18YgZEa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWFiZxAAoJEN0jrNd/PrOhtq8QAI0hcw4hxGZU3IifSUqmF+cA Qd2yIeuv9BRDWq80bq7ZUk+l6DVVECHrFH5N1Xb7RWA+mokpzh8qAr0Qd8KkE/E7 V61flaef6w9v4JGUzKcWRbWTlVTo2Cy9KGK7noyrgrfnaZbQvSAXBDrWzrtgEIJP n5zlvkn3WRQVL85j6uBCwSMZXyr1jHtFB8JYAHVcA+YRItmUYZLBl2A/BOHg+0zp +EezUmupPe8BZ40UEwv053isRW683AFGViv/jm/GAVl+Nha8eNvD2b+9awu+otZR FLLxTNVL61gebKTl03tqKZ8GMFjWSgq5HQsKgXVb89MHRv8qMJ/J+fqHy1XQ7aO3 cLZ6R+WQzFecRKmlAE9K3GFYOtvSk/9f1dh2/Dh2zDqgUEgt3mSSjEtJmPGhOTfM VQR7xYZ0DkbxPNX9dY2k1QPRa7W9SbsE7Di+HV/9P0bnFdVhv5pVa6KBCPIsnB/8 N20PQNfvqQVecbRpHIBxbLWuoMn1UABuIHoTsXC5yaLM76JS955LBO5xRDuUaHd6 /sdvpqdhEQ7QrgG+rosesDKrnqQIGn389qFDrdUezyRB8Hr1+2uki+6CASSwRc5t YDZB3VqUn+iLotEqYtZFQZUqsCqekjGaZG363CVfAizP8yfdrijY6VvSU6z2t8TO 4hbMpaMgusUXg+xvufG0 =iuki -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa-- --===============1513275428== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1513275428==--