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

Harry Wentland harry.wentland at amd.com
Thu Mar 22 14:25:04 UTC 2018


On 2018-03-22 09:04 AM, Sean Paul wrote:
> On Thu, Mar 22, 2018 at 11:53:29AM +0200, Jani Nikula 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.
> 
> Yeah, my apologies for jumping the gun, I had assumed TODO was more wiki style
> than the rest of the tree. I'll make sure it bakes on list next time.
> 

What's the generally accepted bake time on the mailing list for patches with existing ACK or RB before merging?

I'd usually go with a couple working days, up to a week, depending on my assessment of the potential contentiousness of a patch.

Harry

>>
>>>
>>>  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?
> 
> -misc-next is at least the same. It'll be easier for my workflow since I won't
> need to manually copy/paste the entries over from gitk to the tag, but I
> certainly can't speak for others. I was thinking this could be hidden behind a
> DIM_TEMPLATE flag for those who want it.
> 
> Again, I'm sorry for the direct push, won't happen again.
> 
> Sean
> 
>>
>> BR,
>> Jani.
>>
>>
>> -- 
>> Jani Nikula, Intel Open Source Technology Center
> 


More information about the dim-tools mailing list