Re: [PATCH xserver 0/6] modesetting: add DRI2 page flip support

[Keith Packard <keithp-aN4HjG94KOLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1963 bytes --]

Michel Dänzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org> writes:

> This does mean though that if one has only up to patch 3 applied (e.g.
> during a bisection), one is exposed to the issues fixed by patch 4. So
> maybe patch 4 should be squashed into patch 3.

That's a very important point -- developing code in small logical steps
is a most excellent plan, but the resulting set of commits in git need
to satisfy different requirements:

 1) Make forward progress; no commit should regress any functionality,
    no commit should introduce compiler warnings (or, even worse,
    compiler errors). Adam Jackson has reminded me several times to use
    'git rebase -x make' to check a long sequence of patches with the
    compiler. Sometimes I remember on my own.

 2) Each patch should be a single change, self contained and easy to
    understand. If you can't summarize the patch in one line, it's
    probably too complicated for anyone to review effectively. If you
    ever use the word 'and' in the summary line, that's a good sign that
    the patch does more than one thing and should be split apart.

 3) The series should tell a good story. Just like writing a book, the
    final product (sequence of patches or storyline) almost certainly
    will not be presented in the original development
    order. Splitting/merging patch chunks and reordering commits is
    almost always necessary in a long patch series.

I think review takes time related to some high order polynomial function
of the patch length; maybe just quadratic, but possibly more. Long
patches that are purely mechanical changes (replacing function names,
cleaning up whitespace) might be an exception to this rule. Remember
that development is a shared activity, and that spending time making the
patches easy to review moves work from reviewer to committer, and that
is almost always a net win in total development time.

-- 
-keith

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 810 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel