[Mesa-stable] Should we add new error cases to stable releases?

[Kenneth Graunke]

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