Re: [RFC] splitting dri-devel to drm core and drivers lists?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux