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

[Dave Airlie]

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?

to produce drivers for graphics hardware.
to produce something that Linux distributions can consume in a useful
manner. Like if you want to know where mesa is shipping most units,
its in Ubuntu and Fedora, there is probably 100-1000 more copies of
mesa shipping in these two distros than everything else ever produced
by this project.

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.

It means we lose the ability to have stable driver maintainers, as
cherry picking isn't allowed. So for instance I have 2-3 developers
who are stabilising master as hard as they can for the next release,
I'd like to out-of-line pull some of those fixes into stable and not
have the world end. If every developer has to maintain development and
stable trees its a major duplication of resources vs one developer
once every couple of weeks just pulling back a big load of fixes to
stable, and doing a regression run across them, and bisecting out any
regressions before pushing the whole lot to stable. Now I can
cherry-pick a bunch of fixes to 7.8 now off-line, but I still end up
having to merge that back to master and retest master for breakages,
instead of concentrating on making the stable backport work properly,
so it makes me waste a lot of the limited resource which is developer
time.

So here is the thing I can totally see how the current driver model
would be advantageous to the subset that is (a) drivers that don't
ship in the distro channels, and (b) drivers that have a lot of
development resources where developers can live on the stable branch
for long periods of time. However I question whether this is
optimising for the right set of people, considering the number of
units of mesa shipping in the distro channel and the overheads to
community driver developers.

Dave.