Comment 56 for bug 1158689

(In reply to comment #37)
> This also means that you are NOT regularly pulling the updates from Linus'
> central git into the nouveau git, but typically only do this ONCE after
> Linus released a new version (here: 3.4.0)

That usually is done as often as necessary; if one does it more often, it could lead to situations where you have pulled a new broken commit that could slow down Nouveau development. And thus, pulling major releases is efficient.

> and then NOT for any minor
> subsequent release by Linus (3.4.1, 3.4.2 and so on)

Note that those releases happen by Greg KH and consist of backported patches.

> but ONLY shortly
> before he opens the "rc" pull window for his next release series (here:
> 3.5-rc1).

That would be one possible moment where the conditions are ideal enough to pull.

Though I am in doubt whether it matters when this was pulled from Linus. If you don't like to bisect the Nouveau development branch, you can bisect kernel git.

> Besed on this, I did further testing:
>
> Both "5e120f6e4b3f35b741c5445dfc755f50128c3c44^" and
> "5e120f6e4b3f35b741c5445dfc755f50128c3c44" do still run fine, i.e. the
> commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 - which actually introduced
> the nv84_fence - does NOT seem to be causing the distortion issue.
>
> I will now move forward (slowly, as I need to do the tarball-based rpmbuild
> process), and keep you updated on my findings.

You really want to be doing a git bisect to do the least amount of work; I don't see what you mean by "move forward" but I really hope that you are testing the commits in a binary tree style.

You can put the tarball-based process in a script so you only need to run a single command after moving further in the bisection.