[Mesa-dev] [RFC] Mesa 9.2 and release process changes

[Kenneth Graunke]

On 07/03/2013 06:01 PM, Carl Worth wrote:
[snip]
> I can guess a few items:
>
> * Patches must be bug fixes only, not feature work.

Essentially, no new GL features - but hardware enabling is okay.  For 
example, backporting basic Bay Trail support would be OK.

Performance patches are also generally not candidates, unless an 
application's performance is so terribly bad that it's unusable or 
severely regressed.  The optimization must also be non-controversial and 
the patches still need to meet the other criteria of being simple and 
self-contained.

> * Patches must not introduce any regressions
>
> * Patches must have previously been accepted on the mesa master branch
>    (what time window shall we impose here?)
>
> * Patches must be fairly self-contained, (not dependent on a large
>    series of unrelated work)
>
> * Patches must be small (doesn't the kernel successfully impose a limit
>    on the number of lines of patches for the stable tree?)
>
> * The stable-release manager has wide discretion to interpret the above
>    guidelines and reject patches as he sees fit, (and of course the
>    community has wide discretion to reject the stable-release manager as
>    they see fit and appoint a new one)
>
> Something like that perhaps?

This seems pretty reasonable to me.  We may want to tweak things, but 
you've captured the essential idea.