On 07/03/2013 06:01 PM, Carl Worth wrote:
Ian Romanick <i...@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-sta...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
