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

[Sean Paul]

On Thu, Mar 22, 2018 at 01:20:41PM +0200, Jani Nikula wrote:
> 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.

Yeah, I have filters setup to flag 'drm: ' subjects, but that is obviously
somewhat leaky. 

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

It seems like this change would only benefit people who have their own dedicated
driver list, since all others would need to subscribe to drm-drivers?
Perhaps that dedicated subset is big enough to justify the split?

> Thoughts?

I'm not opposed to it. Another subscription has very little impact on me one way
or another.

Sean

> 
> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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