On 02/16/2012 07:08 AM, Brian Paul wrote:
On 02/15/2012 04:28 PM, Ian Romanick wrote:
Over the last six months a lot of feature work has happened in Mesa,
and the load has been carried by a lot of different people /
organization. In the process, we discovered a number of development
process issues that made things more difficult than they needed to be.
The biggest problem the we encountered was the number of features
marked "50% done" in GL3.txt. To complete these features, a
significant amount of time had to be spent figuring out what was done,
and what was left to do. Since the changes had landed on master a very
long time ago, this was a frustrating and error prone process.
Transform feedback was the worst case of this. One developer spent
several weeks trying to assess the state of development. In the
process, a couple items were missed and not detected until early January.
In the future the developer could just send an email to the person who
last worked on the feature asking "what's the status of this?". With
git-blame it's easy to see who last touched a section of code or the
corresponding line in the GL3.txt file.
git-blame tells a lot, but it doesn't tell the whole story. Big
features like transform feedback or integer textures hit code all over
the place. It's really hard to track all of that down. The new
function entrypoints, setting up the dispatch tables, new enables, new
gets, etc. The archaeology is nontrivial.
I'd be happy to answer such queries and I think others would too.
That presumes:
a) The author remembers. A lot of the transform feedback code landed a
around March 2010. That made it over a year old when Dan started. I
surely don't remember the details of any of my partial branches from a
year ago. :)
b) The author is still around. Quite a number of people only hang
around the project for a short time. Who would a person ask about the
DX11 state tracker, for example?
PROPOSAL: No feature will be merged to master until a vertical
slice[1] of functionality is complete.
To be specific, this means that some useful workload should be able to
correctly execute. This doesn't mean that everything is done or even
that any particular real application needs to work. At the very least
there should be a demo or piglit test that uses the functionality in
its intended manner that works.
This means that some incomplete features may sit on branches of a long
time. That's okay! It's really easy to see what has been done on a
branch because you can 'git log origin/master..EXT_some_feature'. This
trivializes the assessment of the state of development.
This sounds good in general. Are you concerned about the gallium code
too? Personally, I'm fine with Dave chipping away at GL 3 support in
gallium (for example) without completing a full vertical slice.
At this point, the vertical slice for the GL 3.0 stuff is done.
I'm thinking of future "big" things like uniform buffer objects,
tessellation shaders, shader image load / store, etc. I can see someone
trying to land only the shading language portions of those or only the
linker portions, for example. That's the case where we have a big blob
of untested (and untestable) code laying around. I want to avoid that.
One thing that /could/ mitigate this is unit tests. A partial piece of
functionality with unit tests to exercise the implemented bits (and
thereby document what has been done) would be a different situation
altogether.
We encountered similar problems with pieces of functionality that were
ostensibly done. Many elements of OpenGL functionality are like Koch
snowflakes: everything is a corner case. Integer textures and
floating-point textures are prime cases of this. Even though the
implementation was done and enabled in several drivers, we had no way
to assess the quality. The same problem holds in cases of features
that are known to be incomplete, even if a vertical slice is functional.
PROPOSAL: No feature will be merged to master until a robust set of
tests are implemented or at least documented.
Sounds good too.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
