On Mon, Mar 26, 2018 at 09:42:52AM +0300, Joonas Lahtinen wrote: > 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. If we could filter on paths this would be trivial. Unfortunately mailing lists, but I do think that for a sufficiently smart mailer you should be able to filter on diff paths for patches (and then tag the entire thread). Ideally we could provide that as a server-side premade filter, but alas it's mailman. So yeah I think the real long-term fix for this is switching to gitlab.fd.o. And as mentioned I think dri-drivers isn't big enough to be sustainable on its own. -Daniel > > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
