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

Jani Nikula jani.nikula at linux.intel.com
Thu Mar 22 11:20:41 UTC 2018


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.

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.


-- 
Jani Nikula, Intel Open Source Technology Center


More information about the dim-tools mailing list