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

[Eric Anholt]

On Fri, 30 Apr 2010 12:13:23 +1000, Dave Airlie <airlied at gmail.com> wrote:
> So in the spirit of being less of a dickhead,
> 
> Lets have a development model discussion. Can anyone who has an
> interest in the development model please answer the two questions
> below in their view/opinion.
> 
> a) what are the goals of the mesa project and development model?

The goal of the Mesa project I want to be working on is: To produce
open-source OpenGL drivers for Linux (/open-source) platforms.

> b) how does the current development model impact those goals.
> 
> The current development model seems to be designed around the VMware
> working model, not the distro working model. I'm not sure what to call
> the VMware working model other than that. I call it that because we
> used to have the TG working model and its not the same as that, and
> its not the same as any other Linux shipped projects working model.
> 
> (The TG model didn't work so well either but it was part of TG's
> business model and we had a smaller community back then, it mainly
> consisted of driver code drops appearing at misc times and releases
> happening on a whenever we have time approach, this was fine then I'm
> not sure with it now, also CVS sort of drove a lot of the problems.).
> 
> So whats wrong with the current model. It basically seems to suggest
> that everyone working on mesa should be working on the stable branches
> and not mainline. Why? 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. Then I can
> keep going working on my feature, the other key problem is I as a
> developer have to understand what is suitable for stable and what
> isn't. I don't think every developer needs to be responsible for this
> decision. It also makes the merge history hella ugly but we can get
> over that.

This is what I actually have to do to participate in the stable branch
according to Brian's rules.  I really do want to be bringing patches to
stable.  I also have the work time to do so.  But the current process
has made me quit.

When I'm producing fixes for Mesa, it's generally because I'm working on
some other interesting thing on master, notice the bug, reproduce it,
start hacking on a fix, come up with the minimal testcase, clean up the
fix, and push it.  If I am to follow Brian's rules, I need to go to my
stable tree, run the testsuite, pull my hacks out of master and clean up
the fix there, test it, push, go to the master tree, run testsuite,
merge stable, run testsuite, and push.  And in the meantime someone
conflicted with me and I get to re-merge and test and despair.  So
Brian's rules make a simple fix not related to my primary task for the
day go from 2 testsuite runs on 1 tree to 4 testsuite runs on 2 trees.

I will not merge to master without testing.  Every time I push changes
without testing, they're broken.  And that doesn't appear to be
significantly different for other people that have merged stable changes
into master in my drivers.

So, I have realized that if I follow these rules, I will simply ignore
small bugfixes I ought to do because it's too much of a distraction from
what I need to be doing.  Instead I just develop on master, ignore
stable, and hey at least the next major release will be better.

(For a while I was cherry-picking to stable and ignoring Brian's rules.
I got yelled at enough about this by people who wanted me to put my foot
down about this bad model instead of ignoring it that I just quit
entirely).

If the VMware guys will stop merging stable to master, I will start
cherry-picking fixes to my driver back to stable again.
-------------- 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/bae2321a/attachment.pgp>