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

[Ian Romanick]

On 07/03/2013 06:01 PM, Carl Worth wrote:
> Ian Romanick <idr at freedesktop.org> writes:
>> 1. Carl Worth is taking over stable releases from me, so I'd like to
>> increase the rate of stable releases from (nominally) monthly to every
>> two weeks.
>
> Thanks. I'm happy to help here. So I'll plan to release 9.1.5 on July
> 15, (just 1.5 weeks away now).
>
>> Instead of the current system, I'd like to propose creating a
>> mesa-stable mailing list where candidate patches will be sent.
>
> I got some feedback from some committers that they are happy with the
> current system of nominating commits in the commit message. So I'm happy
> to use mesa-stable@ in addition to that rather than replacing it.
>
> But, yes, to the extent that anyone feels that they are currently
> over-annotating commits "just in case", (and knowing they can't edit the
> commit messages after the fact), please feel free to switch to using the
> mesa-stable@ list instead.
>
> I did just create the mesa-stable at lists.freedesktop.org mailing list, so
> people can start using that email address immediately for proposing
> patches to be included on the stable branch.
>
> I've configured the list to accept messages from anyone currently
> subscribed to the mesa-dev mailing list, (other than the 8 private
> members whose addresses I could not obtain). For anyone else, messages
> will be held in moderation which I will push through. So nobody needs to
> subscribe unless they want to, (but anyone can if they would like to).
>
> The subscription page is available here:
>
> 	http://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
>> As part of this, we need to clearly document the criteria for inclusion
>> in the stable branch.  We have some vague criteria now, but we should
>> formalize and agree on the list.
>
> Yes. Can people please send here what they would like the criteria to
> be? Then I will add the criteria to the description of the mailing
> list.
>
> I can guess a few items:
>
> * Patches must be bug fixes only, not feature work.
>
> * Patches must not introduce any regressions

We may want to define this more precisely.  Not breaking the build from 
some predefined set of configurations is a good start.  Not causing 
piglit regressions for [some defined thing] would be another good thing.

> * 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)

I believe we should also have a window around the release where new 
patches are not allowed to land.

> Something like that perhaps?
>
> I plan to put together an automatically-updated web-page showing the
> status of outstanding patches sent to the mesa-stable list, (whether
> merged, rejected, waiting for time on the master branch, etc.). It might
> be based on something like this:
>
> 	http://nmbug.tethera.net/status/
>
> So I'll announce that if/when I put that together.
>
> Anything else anyone would like to see for stable releases?
>
> If not, please start nominating patches!
>
> Thanks,
>
> -Carl