On 07/30/2013 12:13 PM, Carl Worth wrote:
Hi Ken,In the last stable-release cycle you argued for not cherry picking commit fcaa48d9cc8937e0ceb59dfd22ef5b6e6fd1a273 on the grounds that we shouldn't change mesa to be strictly more strict in a stable release. That is, adding a new error case to the compiler cannot actually cause a valid program to start working, (which would be a nice bug fix), but could potentially cause an invalid program to stop working (which could be regarded as a regression). The same reasoning seems to disqualify the below patch. Do you agree? Anyone else have input on this issue? If we agree on the rationale, I'd like to codify it with some language in our documentation for stable-branch criteria. Something like: Note: Not all bug fixes are automatically suitable for the stable branch. For example, a patch that makes the implementation more strict, (such as detecting some invalid GLSL code that was previously silently accepted), can be rejected by the stable-branch maintainer. The rationale is that a patch like this can cause a program which was previously working as desired to now stop working due to the new error case. From the point of view of the user of such an application, that's a regression that we do not want to allow during a stable release. -Carl
I agree that disallowing "centroid out" is not something that should be cherry-picked back to 9.1, since it won't fix valid applications.
My intention here was for the patch to go to 9.2, which has completely rewritten qualifier handling. Since 9.2.0 isn't out yet, it's not a risk of breaking things in a point release. It's a matter of getting bug fixes into the major release before it comes out.
--Ken _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
