[Mesa-dev] [RFC] Merging feature work to Mesa master

[Ian Romanick]

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