[Intel-gfx] [RFC] splitting dri-devel to drm core and drivers lists?

Daniel Vetter daniel at ffwll.ch
Fri Mar 23 16:39:04 UTC 2018

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.

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 Vetter
Software Engineer, Intel Corporation

More information about the Intel-gfx mailing list