* [RFC] splitting dri-devel to drm core and drivers lists? @ 2018-03-23 16:22 Jani Nikula 2018-03-23 16:39 ` Daniel Vetter 0 siblings, 1 reply; 6+ messages in thread From: Jani Nikula @ 2018-03-23 16:22 UTC (permalink / raw) To: dri-devel; +Cc: intel-gfx, dim-tools, Daniel Vetter, Dave Airlie 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 -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] splitting dri-devel to drm core and drivers lists? 2018-03-23 16:22 [RFC] splitting dri-devel to drm core and drivers lists? Jani Nikula @ 2018-03-23 16:39 ` Daniel Vetter 2018-03-26 6:42 ` Joonas Lahtinen 0 siblings, 1 reply; 6+ messages in thread From: Daniel Vetter @ 2018-03-23 16:39 UTC (permalink / raw) To: Jani Nikula; +Cc: intel-gfx, dim-tools, Daniel Vetter, dri-devel, Dave Airlie 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] splitting dri-devel to drm core and drivers lists? 2018-03-23 16:39 ` Daniel Vetter @ 2018-03-26 6:42 ` Joonas Lahtinen 2018-03-26 7:43 ` Daniel Vetter 0 siblings, 1 reply; 6+ messages in thread From: Joonas Lahtinen @ 2018-03-26 6:42 UTC (permalink / raw) To: Daniel Vetter, Jani Nikula Cc: intel-gfx, dim-tools, Daniel Vetter, dri-devel, Dave Airlie, harry.wentland 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] splitting dri-devel to drm core and drivers lists? 2018-03-26 6:42 ` Joonas Lahtinen @ 2018-03-26 7:43 ` Daniel Vetter 2018-03-26 8:00 ` [Intel-gfx] " Jani Nikula 0 siblings, 1 reply; 6+ messages in thread From: Daniel Vetter @ 2018-03-26 7:43 UTC (permalink / raw) To: Joonas Lahtinen Cc: intel-gfx, dim-tools, Jani Nikula, Daniel Vetter, dri-devel, Dave Airlie, harry.wentland 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 -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Intel-gfx] [RFC] splitting dri-devel to drm core and drivers lists? 2018-03-26 7:43 ` Daniel Vetter @ 2018-03-26 8:00 ` Jani Nikula 2018-03-26 8:53 ` Daniel Vetter 0 siblings, 1 reply; 6+ messages in thread From: Jani Nikula @ 2018-03-26 8:00 UTC (permalink / raw) To: Daniel Vetter, Joonas Lahtinen Cc: intel-gfx, dim-tools, Daniel Vetter, dri-devel, Dave Airlie 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. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] splitting dri-devel to drm core and drivers lists? 2018-03-26 8:00 ` [Intel-gfx] " Jani Nikula @ 2018-03-26 8:53 ` Daniel Vetter 0 siblings, 0 replies; 6+ messages in thread From: Daniel Vetter @ 2018-03-26 8:53 UTC (permalink / raw) To: Jani Nikula Cc: intel-gfx, DRM maintainer tools announcements, discussion, and development, dri-devel, Dave Airlie, Wentland, Harry 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-03-26 8:53 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-03-23 16:22 [RFC] splitting dri-devel to drm core and drivers lists? Jani Nikula 2018-03-23 16:39 ` Daniel Vetter 2018-03-26 6:42 ` Joonas Lahtinen 2018-03-26 7:43 ` Daniel Vetter 2018-03-26 8:00 ` [Intel-gfx] " Jani Nikula 2018-03-26 8:53 ` Daniel Vetter
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.