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?
BR, Jani.
[1] http://mid.mail-archive.com/87d0zwicfq.fsf@intel.com
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
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, 26 Mar 2018, Daniel Vetter daniel@ffwll.ch wrote:
And as mentioned I think dri-drivers isn't big enough to be sustainable on its own.
It certainly is big enough to be disruptive to my inbox, and I don't seem to be alone.
BR, Jani.
On Mon, Mar 26, 2018 at 10:00 AM, Jani Nikula jani.nikula@intel.com wrote:
On Mon, 26 Mar 2018, Daniel Vetter daniel@ffwll.ch wrote:
And as mentioned I think dri-drivers isn't big enough to be sustainable on its own.
It certainly is big enough to be disruptive to my inbox, and I don't seem to be alone.
If you want to make this happen, convince all those driver folks that this will benefit them. That's essentially how intel-gfx and the amdgpu list happened, and it's also kinda why nouveau is special (well it's developed entirely in userspace somewhere else). I just wanted to highlight that I don't see much benefit (if there is any) from the smaller-drivers point of view, and hence that your proposal will face an uphill battle. -Daniel
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Jani Nikula -
Joonas Lahtinen