From mboxrd@z Thu Jan 1 00:00:00 1970 From: SF Markus Elfring Subject: Re: GPU-DRM-OMAP: Fine-tuning for several function implementations Date: Thu, 22 Sep 2016 11:11:16 +0200 Message-ID: References: <566ABCD9.1060404@users.sourceforge.net> <0ea38611-3d93-0ade-a1fb-f8cc2e0b8d61@users.sourceforge.net> <20160922064501.GF22164@dvetter-linux.ger.corp.intel.com> <3793871.zJbXxf8jdx@avalon> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3793871.zJbXxf8jdx@avalon> Sender: kernel-janitors-owner@vger.kernel.org To: Laurent Pinchart , Daniel Vetter Cc: dri-devel@lists.freedesktop.org, David Airlie , Tomi Valkeinen , Julia Lawall , kernel-janitors@vger.kernel.org, LKML List-Id: dri-devel@lists.freedesktop.org >> For the next pile of driver patches _please_ talk with driver maintainers >> before starting to create&submit patches. Did the software development discussion start a bit here? Would you like to support an other "talking style" on a conference like in Berlin next month? >> Like I said I won't take them, It's a pity. >> and many of your changes are not clear-cut at all, I know that specific update suggestions could be interpreted as controversial. >> so I expect many driver maintaines also won't take them. I am curious on useful responses. >> Again, your contributions are welcome, Thanks for another bit of constructive feedback. >> but blindly following suggestions from code checkers in drivers I propose to dare another look at corresponding information sources. >> you cant test isn't really all that useful. I have got an other impression. How many improvements can still be achieved by usual (advanced) collaboration techniques for free software development? >> At the scale you're doing it, I think it's mostly wasting everyone's time I hope not. > :( I'd like to avoid that. I am going to point more update opportunities out also for various Linux software. > I second that. Thanks for your opinion on this issue. > After a very quick review, I see that the series splits related changes > in multiple patches. I chose a specific patch granularity for this proposal. > I've already commented in reply to another series submitted by Markus > that patches should then be combined. Will such a combination depend on any more agreements between the involved contributors? > I will thus ignore this series completely for the time being. I hope that you can give similar ideas a second chance somehow. Regards, Markus