[DIM PATCH 1/2] TODO: Cc patch authors when tagging and generating PRs

[Joonas Lahtinen]

Quoting Harry Wentland (2018-03-22 16:21:56)
> 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.nikula at linux.intel.com> wrote:
> >>> On Wed, 21 Mar 2018, Sean Paul <seanpaul at chromium.org> wrote:
> >>>
> >>> Please insert rationale here...
> >>>
> >>>> Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> >>>> Signed-off-by: Sean Paul <seanpaul at 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.

Jani must be reading my mind as I was about to make this suggestion
yesterday. So a definitive +1 from me.

Regards, Joonas