On Tue, 2010-04-06 at 09:30 -0700, Keith Packard wrote: > First off, thanks to everyone involved in the 1.8 release; it was a > pleasure to work with you. I'm hoping everyone else is as happy as I am > about our new release process, it seemed to me that we saw a lot more > active review and discussion about proposed patches this time around. > > For version 1.9, I'm planning on doing things in much the same way, if > people have suggestions on how we can improve things, please post them > so we can get things settled before we get too far into the release.
I still think restricting write access to xserver master to a single person has been a mistake, choking existing momentum without generating new momentum, or making master broken less of the time — rather the opposite: There were a number of cases where breakage wasn't fixed for days because nobody else was allowed to push the fixes. Restricting write access to a single person makes a lot of sense for the stable branches (in fact it should have been done for those much earlier), but we cannot afford the overhead for master. Note that I'm not suggesting everybody should get unconditional write access. E.g. people not taking responsibility for changes they push — fixing up or reverting broken changes in due time — obviously shouldn't. Even restricting write access of most people to certain subtrees would be a step forward. One thing that's sorely needed again is a blocker/tracker bug at least for the x.y.0 release. It's been my impression that 1.8.0 was released with a few bugs that should have been fixed or at least seriously considered before, but apparently nobody really had an overview of the situation. In the run-up to 1.7.0 and earlier releases, I would regularly go through the list of blocker bugs and try and fix some of them. (The motivation for that would have been lower now due to the new process costing excessive time and effort to get in simple fixes, but it would have been better) > 4) Ack patches that you think are necessary. An 'Acked-by:' line should > signify that the patch purports to do something that you think is > necessary or useful, but that you haven't reviewed in depth or > tested it. I'd like to encourage people who see an Acked-by line to > consider reviewing and testing the associated patch; all things > being equal, patches that lots of people want should probably be > higher priority than other patches. This seems inconsistent with the usage of this tag in the Linux kernel development process. If we're going to continue shoehorning our project into that process, we should avoid such inconsistencies, or it'll be even worse than merely imposing a process from a different project without serious consideration of the goals and properties of that process and whether those are desirable for our project. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel