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

[Daniel Vetter]

On Wed, Jul 03, 2013 at 10:02:07PM -0700, Kenneth Graunke wrote:
> 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.

I think the kernel's stable rules are fairly reasonable and precise. We
might want to clarify a bit though what level of piglit'ing is expected
for mesa:

https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt

The part about the kernel's stable process I really like is that the
stable maintainer assembles all the backported patches into a queue and
before doing the release sends them out to the stable mailing list for
review. Since all the people on the original patch (author, reviewer,
cc's) are cc'ed on these mails too you can easily nack a patch which was
tagged for backporting but turned out to be broken somehow. After the
review period (maybe 1 week or so) passed the stable queue gets tagged and
pushed to the real stable branch.

Also a nice service from the stable kernel guys is that they'll send you a
nag mail to submit a manual backport if the patch fails to apply cleanly
(or breaks the build somehow).

This way you can aggressively tag patches for backporting, there's no
burden on developers to keep track of patches which should get nominated
after some testing and still there's a reasonable chance that crap doesn't
land in the stable branch.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch