On Thu, Mar 22, 2018 at 01:20:41PM +0200, Jani Nikula wrote: > On Thu, 22 Mar 2018, Jani Nikula <[email protected]> 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. > > > >> > >> 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 _______________________________________________ dim-tools mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dim-tools
