RFC: xserver commit process changes

[Peter Hutterer]

airlied brought this up in another thread [1], but I think this warrants 
a separate, more visible topic.

The current xserver development process can be summarised as:
* patches must be on the list and get a reviewed-by
* pull request to Keith [2] (or direct CC)
* Keith is the only one to push to master

This has worked reasonably well since we started for server 1.8. If 
nothing else, it has made git master a lot more reliable. However, Keith 
is the bottleneck to get anything into master. The delay to get a pull 
request merged has been quite random, depending on Keith's other 
workload. I'm struggling with this a lot at times. Bugs cannot be closed 
even though the work is done, local branches cannot be merged and 
finalised. Apparently others face similar issues.

It's an easy thing to fix, and the end of the 1.14 timeframe is coming 
anyway so now is the ideal time. tbh, I don't want a free-for-all master 
again, but we do need more people with commit access. So an initial 
proposal is:

* leave the current window of 3/2/1-ish months for the different devel 
stages
* leave the requirement for a reviewed-by
* one RM, calling the shots for when releases are made and generally 
being the reviewer of last resort and arbiter where needed
* 3-5 people with commit access during the devel and general bugfix 
windows. They scoop up pull requests and commit them, if the patches 
have rev-by tags [3]
* 2 people during the last bugfix window (emergency fixes only). The 
second person as backup to the RM to make sure we don't see delays.

This is a fairly conservative change, just aimed at removing the current 
bottlenecks. There are other areas of improvement, but they're probably 
subject to a separate discussion.

Volunteers for committers are welcome. Though note that this is not to 
get your own patches in quickly, you'll also have to scoop up and review 
other patches. (fwiw, I volunteer)

Comments?

Cheers,
   Peter

[1] http://lists.x.org/archives/xorg-devel/2013-February/035558.html
[2] technically the "release manager", but Keith has been the RM since 
1.8, so...
[3] this could be automated by a bot, but I don't have time to do set 
this up