X server 1.9 release thoughts

[Michel Dänzer]

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