X.Org Server Development Process Is Questioned

For the past few years the X.Org Server has managed to get back on track for being released bi-annually and without too many delays. However, the server has also fallen into a habit where it's being released without all of the "blocker bugs" being cleared.

Alan Coopersmith raised the issue earlier this month on the X.Org developers' list. "We've never been good about fixing all the bugs on the release tracker, but it appears we've gotten out of the habit of even just reviewing the bugs and moving them forward to the next release when we're done, as most open bugs are still stuck under the 1.12 & 1.13 trackers."

Some bugs end up getting closed while other bugs are just delayed to being fixed to a later release or the bug reports not even being updated. While Coopersmith raised the issue two weeks ago, it didn't spark much of a conversation among X.Org developers about how this situation can be improved upon and corrected.

On Friday a point was raised by a user where one of the bugs was fixed weeks ago, tested by two other stakeholders, posted to the xorg-devel mailing list, but never applied to the X.Org Server Git tree. Under the current X.Org Server development process, Keith Packard of Intel serves as the release manager in a similar position to Linus Torvalds where developers need to call upon him to pull their Git trees / patches to be applied to mainline.

In a new mailing list post on Saturday, David Airlie of Red Hat is now questioning this xorg-server development process that's been going on for the past couple of years. "Yeah I even included it in a pull request that was ignored for ages, and when some bits got applied the rest is still being ignored. At this point I'd like to suggest something is broken and we go back to the mesa style system for master, where anyone can commit once we have an R-b from the list. All in favour say aye?"

David is proposing that the X.Org Server development goes back to the old ways whereby any developer can basically commit directly to the tree rather than queuing up work and waiting for Keith Packard to pull it. This process is similar to how Mesa is developed and avoids bottlenecks and single points of failure. While it's the weekend, so far no other developers have commented on this possible change for how the X.Org Server is developed.

Meanwhile, X.Org Server 1.14 is due for release in early March.