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

Daniel Vetter daniel.vetter at ffwll.ch
Thu Mar 22 14:45:46 UTC 2018


On Thu, Mar 22, 2018 at 3:25 PM, Harry Wentland <harry.wentland at amd.com> wrote:
> 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.

For contentious patches it's good to actively ping people who might
raise opinions over irc. In case of doubt, ask maintainers, it's a bit
an experience thing. I'm also trying to add any regular reviewers for
specific stuff to MAINTAINERS so that this is easier to figure out.

For anything else I just push right after the r-b/a-b is in, and I
think that's perfectly fine. Forcing everyone to endlessly wait isn't
great.
-Daniel

>
> 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
>>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dim-tools mailing list