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 <[email protected]> wrote: > >> > >> Please insert rationale here... > >> > >>> Acked-by: Daniel Vetter <[email protected]> > >>> Signed-off-by: Sean Paul <[email protected]> > >>> --- > >>> > >>> 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 _______________________________________________ dim-tools mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dim-tools
