[Mesa-dev] so the development model is working?

[Eric Anholt]

On Thu, 29 Apr 2010 22:16:51 -0600, Brian Paul <brianp at vmware.com> wrote:
> Dave Airlie wrote:
> """because if I add a new feature to my mainline
>   branch then happen to notice a bug fix along the way, then I have to
>   stop what I'm doing, check out stable, run a test suite, fix the bug
>   in stable, run another test suite, merge stable to master, run a test
>   suite on master before my fix, run a test suite on master after the
>   merge, hope I didn't break 5 other drivers doing the merge."""
> 
> Hmmm, here's how I work:  I have several separate git check-outs in
> different directories.  At the moment I have four that I'm actively
> working on (plus ~30 inactive/older ones).  My active directories
> contain different branches (master vs. 7.8 vs. 7.7 etc) with different
> builds (swrast vs. DRI vs. llvm, etc).  I typically have a terminal/tab
> open on each of my active check-outs.  This lets me quickly and easily
> compare the results of Mesa 7.7 vs. 7.8 vs. master when I find a bug
> or want to compare performance, etc.  Do you really do all your work
> in one directory with just one check-out??

I don't, but that just eliminates the "check-out" step, not the actual
expensive "do testing" steps.

> I'm usually working on master.  If I think I've found a bug (or
> someone reports a bug in 7.8, for example) I just change terminal tabs
> and start debugging in my 7.8 directory.  I don't have to save my work
> on master or check out a different branch, etc.  Just switch to a
> different terminal and fire up emacs.  After I fix the bug, I commit
> it to the 7.8 branch and document it in the release notes file (I'm
> practically the _only_ person who bothers to do that, btw!).  If I
> think it's important to get the fix into master quickly (or there's
> any doubt about applicability) I'll do a merge right away.  Otherwise,
> I just resume whatever I was doing before, knowing that the fix will
> propogate into master whenever we do a merge.
> 
> I think you exagerate how many testing steps you have to do for each
> and every fix.  Absolutely, there are times when thorough testing is
> needed.  But lots of simple bug fixes/changes in 7.8 can be merged
> into master without worry.  I can provide many concrete examples if
> you don't believe me.

Grepping Mesa history for "merge" leads to either laughing or crying.
Here's a sample of "someone thought they didn't need to test a merge and
were wrong" this year, not even changes that went into stable when they
shouldn't have.

commit a098fd71d7b7347bb8f1841bad0e7ce24e0e6de9
Author: Eric Anholt <eric at anholt.net>
Date:   Mon Jan 25 22:27:46 2010 -0800

    i965: Fix build after merge of mesa stable branch.

commit f6a49ac21721353948b03cf3ca3b5aa5c87e59e6
Author: Brian Paul <brianp at vmware.com>
Date:   Fri Jan 22 18:35:36 2010 -0700

    svga: fix up breakage from earlier 7.7 merge

commit 1e4b81267c77567ec9dfb687ccd8f02086053777
Author: Brian Paul <brianp at vmware.com>
Date:   Fri Jan 22 12:27:25 2010 -0700

    gallium/aux: re-add pb_buffer_fenced.[ch] accidentally remove during
    merge

commit 5a7c2a99a65399a59f54c6a0756c106c1ae048ff
Author: Eric Anholt <eric at anholt.net>
Date:   Tue Jan 5 11:07:54 2010 -0800

    i965: Fix build after blind merge of mesa 7.7 by Brian.

Of course, I get complained at for the breakage in my driver, not the
people that did the bad merge.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100430/811dcf81/attachment.pgp>