All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.