On Thu, 29 Apr 2010 22:16:51 -0600, Brian Paul <bri...@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 <e...@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 <bri...@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 <bri...@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 <e...@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.
pgphY1QS7ONok.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
