On Tue, Feb 07, 2017 at 12:11:28PM +0100, Thierry Reding wrote: > On Tue, Feb 07, 2017 at 08:28:16AM +1000, Dave Airlie wrote: > > > > > > I definitely don't want that we don't attempt this. But brought from years > > > of experience, I recommend to merge first (with pre-refactoring already > > > applied, but helpers only extracted, not yet at the right spot), and then > > > follow up with. Because on average, there's way too many trees with > > > overloaded maintainers who maybe look at your patch once per kernel > > > release cycle. > > > > > > If you know that backlight and spi isn't one of these areas (anything that > > > goes through takashi/sound is a similar good experience for us on the i915 > > > side), then I guess we can try. But then Noralf has already written a few > > > months worth of really great refactoring, and I'm seriously starting to > > > feel guilty for volunteering him for all of this. Even though he seems to > > > be really good at it, and seems to not mind, it's getting a bit silly. > > > Given that I'd say up to Noralf. > > > > > > In short, there's always a balance. > > > > I don't think we can make a rule for this, it will always depend on the > > code. There is always going to be stuff we put in drm that should go > > elsewhere, and stuff that is elsewhere that drm should use. > > > > I think however if we do add stuff like this, someone should keep track > > of them and try to make them get further into the kernel. > > Yes, I think having some sort of TODO in drivers/gpu/drm could help > track things that we know should eventually be moved out. It could serve > as a list of janitorial tasks for newcomers that want to get their hands > dirty and tackle relatively trivial tasks. We have this list already, it's at: http://www.x.org/wiki/DRMJanitors/ I guess I should highlight it more, maybe even add it to the docs? Eric just asked about it last week too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
