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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
