[Mesa-dev] [RFC] Merging feature work to Mesa master
brianp at vmware.com
Thu Feb 16 07:08:29 PST 2012
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.
I'd be happy to answer such queries and I think others would too.
> PROPOSAL: No feature will be merged to master until a vertical
> slice 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.
> 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.
More information about the mesa-dev