On 2018-03-22 09:13 AM, Sean Paul wrote: > On Thu, Mar 22, 2018 at 01:20:41PM +0200, Jani Nikula wrote: >> On Thu, 22 Mar 2018, Jani Nikula <jani.nik...@linux.intel.com> wrote: >>> On Wed, 21 Mar 2018, Sean Paul <seanp...@chromium.org> wrote: >>> >>> Please insert rationale here... >>> >>>> Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch> >>>> Signed-off-by: Sean Paul <seanp...@chromium.org> >>>> --- >>>> >>>> Pushed with danvet's IRC ack >>> >>> Sure it's "just" a documentation patch, but please let's stick to the >>> practice of sending patches out to the list and giving people a chance >>> to comment before pushing. >>> >>>> >>>> TODO.rst | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/TODO.rst b/TODO.rst >>>> index 76b00a1873df..154795027c27 100644 >>>> --- a/TODO.rst >>>> +++ b/TODO.rst >>>> @@ -18,6 +18,8 @@ dim >>>> first for rebuild-nightly to pick it up, which means the merge can't be >>>> fixed any more. >>>> - apply-resolved fails to add the Link: tag. >>>> +- Harvest and add Cc labels to all authors when tagging a branch >>>> +- Parse Cc labels from tag body and add as email headers when sending >>>> pull requests >>> >>> So I guess this is useful especially for people not subscribed to >>> dri-devel to see where their patches are going. drm-intel-next regularly >>> has 20-30 authors per pull request. I'm just a little bit hesitant about >>> the noise. Do you think the benefits outweight that? >> >> PS. Part of this concern comes from me just recently wondering (thus far >> just by myself) if we could split the dri-devel list to core patches and >> drivers patches. >> >> 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. > > Yeah, I have filters setup to flag 'drm: ' subjects, but that is obviously > somewhat leaky. > >> >> 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. >> > > It seems like this change would only benefit people who have their own > dedicated > driver list, since all others would need to subscribe to drm-drivers? > Perhaps that dedicated subset is big enough to justify the split?
I think it's a good idea and might make dri-devel more accessible. Harry > >> Thoughts? > > I'm not opposed to it. Another subscription has very little impact on me one > way > or another. > > Sean > >> >> BR, >> Jani. >> >> >> -- >> Jani Nikula, Intel Open Source Technology Center > _______________________________________________ dim-tools mailing list dim-tools@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dim-tools