RFC: group maintainership for misc drm trees

[Daniel Vetter]

On Tue, Feb 16, 2016 at 2:44 AM, Dave Airlie <airlied at gmail.com> wrote:
> I'm finding with i915 for example there is a massive latency in the pipeline now
> waiting for fixes, and the pipeline to the end of drm-intel-next is
> very long and
> hard to figure out what fixes should be pulled back, and how much of the
> driver has been rewritten between the -next and the -fixes pulls.

I think this is a separate topic, so I'm making that into my own reply.

What's your target here, or what would you like to see changed? More
transparency in how -fixes flow to drm-fixes ultimately? For you, or
for the fix submittter?

We've discussed this already on irc in the context of Lyude's patches,
and those showed up on intel-gfx on 2nd/4th Feb and landed in your
inbox as a pull request on 14th, so about 10 days. And most of that
was because I was at LCA. Some intel-written fixes got delayed a bit
more because CI was down in-between, too. But now that we have CI
(even though just basic) I really don't want to ignore it, since the
past two times it was down an unrelated overlapping regression crept
into drm-intel-next. And that's just pain. Given that I think we're
definitely not doing things perfectly (Jani needs a reminder for
timely pull requests), but overall it seems to work ok. And lots more
patches seem to flow to -fixes I think.

Or do you have some other patches in mind?

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