Recapping The New X.Org Development Process

Scheduling issues had plagued X.Org Server development for the past few years: to the point that even delivering a point release had come more than a year late and major X Server releases were never delivered on time. This though has fortunately changed.

With X.Org Server 1.8 though it was proposed to make some fundamental development changes and better refining the X.Org development process to be more like the Linux kernel -- though not the same -- where there is an official release manager, timed releases, and a defined process for requesting changes/patches be pulled into a given release. Since that point, the X.Org Server has basically been released on time. X.Org Server 1.9 was released on time just last month.

At XDS 2010 in Toulouse, France, Keith Packard and Peter Hutterer just finished talking about this development process. No major development process changes were proposed or altered. Again, the three phases of the server development process as described by Keith is the "free for all" process when anything new can enter the server (similar to the Linux kernel "merge window" during each cycle), then the stabilization period, and lastly is the API/ABI freeze for the release.

Here are a few other random notes from this discussion:

- Using a BugZilla release blocker bug for X.Org Server development has worked out really well. "If you bring an X.Org bug up to being a release blocker status, we'll look at it."

- Unless it's a security issue, Keith would not hold-up an X.Org Server release for no blocker bugs. "It's hard to say we have any new security holes, but lots of old ones."

- There's a need for X.Org and distribution/OS vendors to work together in a more efficient and effective manner. For example, there's many OpenBSD patches that still have not been pulled upstream.

- "Is the review process stifling change?" Adam Jackson called for more developers to become involved in the review/patch acceptance process beyond Peter, Keith, and him. Adam thinks the rate of code change since this new development process has decreased as a result of this new development process. Keith says this is because of the complexity of the code and that the current X.Org server "does what it does" and is better advancing than in the past.

- In the future when patches are pulled in by Keith Packard for changes to the X.Org Server, he will now reply and acknowledge the commit via e-mail rather than leaving developer to wonder about its state, monitor the commit list, or be frequently pulling the xorg-server Git code.

- Red Hat's Adam Jackson and Apple's Jeremy Huddelston are taking over management of the X.Org Server 1.9.x stable series.