Quoting Daniel Vetter (2018-03-23 18:39:04) > On Fri, Mar 23, 2018 at 06:22:46PM +0200, Jani Nikula wrote: > > There was some discussion on the dim-tools list about splitting the > > dri-devel list to drm core and drivers lists [1]. Moving the discussion > > to the list in question seems prudent. ;) > > > > I freely admit I don't have the time or interest in reading the patches > > for other drivers than i915, but I do glance over almost everything > > touching drm core. > > > > I'd like to encourage i915 developers to stay up to date on what's > > happening in drm core, but the firehose of dri-devel can be a bit > > daunting to handle. From this perspective the S/N on dri-devel is not > > great. YMMV, obviously. > > > > Feels overkill to require all small drivers to have lists of their own, > > and that would also be counter productive to the ideal that they'd try > > to review each other's work. Hence the idea of having a, say, > > dri-drivers or drm-drivers list. > > > > Thoughts? > > I think especially for small drivers it makes sense to refactor a bit > more, to make them even smaller. The bigger drivers can and do afford to > invent their own dedicated wheels for many things, which make sense. So I > see plenty of benefit in having the small drivers and core bits all in one > huge pool. > > There's also the question of whether we should then split drm-misc, and I > think drm-misc as purely the core thing without the small drivers > bandwagon is much less sustainable (because too small). So I'm not sure > splitting drm-misc would be a good idea. And split dri-devel without split > drm-misc is going to be a pain I think. The original suggestion (at least my conception of it) could be rephrased as just having dri-drivers for all the drivers without a dedicated mailing list. It'll surely be easier for the developers to join dri-devel + dri-drivers than for others to try to filter out the driver traffic. With a simple logic of if you're touching drm outside of your own driver folder, Cc: dri-devel. You can only get the DRM core "tagging" by filtering out everything else, which never works so great. Regards, Joonas > > I think a quick mail filter that marks anything which isn't tagged as the > drm core as read is a good option. It's what I do too. With a bit better > infrastructure we could provide that filter to everyone, but alas, we're > stuck on mailing lists so that's just it. > > Wrt encouraging more intel folks to look at what's happening in the drm > core: My cunning plan is to just throw commit rights at a bunch of them, > on average that seems to get the job done. I'll start nominating people as > soon as we have the drm-intel commit right story sorted. I do think we > have quite a pile of people involved in drm core work, that itself isn't a > problem I think. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
