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
