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

[Harry Wentland]

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.

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
>