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

[Sean Paul]

On Thu, Mar 22, 2018 at 10:25:04AM -0400, Harry Wentland 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.

I think it depends on the strength of the Ack/Review (ie: if it comes from the
driver maintainer, or a fly-by by someone else), as well as the complexity of
the patch. However as discussed upthread, my model might not be the best one to
follow :-)

Sean

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

-- 
Sean Paul, Software Engineer, Google / Chromium OS