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

[Daniel Vetter]

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 at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch