1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Proposed Process Changes For X Server 1.8

X.Org

Published on 26 September 2009 12:10 PM EDT
Written by Michael Larabel in X.Org
21 Comments

While the X.Org developers are responsible for a lot of critical code and much of it is quite old and massive, they are often challenged by hitting a release on time and often face multiple release schedules before coming close to delivering a new X Server / X.Org release. Just take a look at X.Org 7.4 Finally Released, X.Org 7.5 Released. Wait, Nope!, or X Server 1.4.1 Is Released, No Joke as recent examples. With the X Server 1.7 / X.Org 7.5 release cycle that we are finally getting close to ending, it took multiple tries and is coming out over six months later than expected. Granted, there is Multi-Pointer X support and other new improvements, but concerns about the degrading quality of releases have been voiced for years. Fortunately, this situation may finally turn around.

Peter Hutterer, who has been working on the X.Org input code for some time and is the developer behind MPX, late into the X.Org 7.5 release cycle decided to step up to the plate and personally get this important X.Org update out the door. Peter is not stopping after X Server 1.7, but has already made a proposal regarding the release and development changes going forward for X Server 1.8 and into the future.

Peter acknowledges the current key problems with the X.Org release schedule being unpredictable, Git master is unusable at times, and there is a late testing cycle. Mr. Hutterer is proposing three fundamental changes and they include the use of feature branches, three stages to the development cycle, and predictable time-based releases. With regard to feature branches, Peter proposes that all work that is large and potentially disruptive to the X Server stability should first be done in a branch of the X Server rather than in Git master. Once the branch is developed, tested, and fairly sane it could then be pushed along into the master branch. Peter cites his Multi-Pointer X development work last year as a good example of a feature branch working out well.

The three stages of the proposed development cycle for X.Org would be feature merge, bug-fix, and release freeze. The merge window for the X Server would be open for about three months at a time followed by two months of bug-fixing and then a one month period for the X Server to be frozen and well-tested prior to a release. This would allow consistent six-month releases of the X Server / X.Org. Albeit with different time lengths, this would put the X.Org development process much closer to that of the Linux kernel. Feature branches ready for the next release would be merged into Git master during that time, followed by bug-fixing afterwards, and then at the end it's time to cut the release and then branch the X Server. The X Server would not be branched in advance of a release, but rather afterwards and prior to the next release's merge window opening.

Lastly, Peter calls for predictable time-based releases and not to delay any releases based upon half-complete features. As part of getting X.Org released on time, he also calls for monthly snapshots of Git master for easier testing and then towards the end of the cycle to provide weekly or bi-weekly snapshots until the release candidates are pumped out. Having predictable time-based releases would please quite a lot of people, especially the distribution vendors that have been challenged in the past by deciding whether they can switch to the next X.Org / X Server in their development cycle or whether delays will jeopardize the move and postpone it to their next release.

Peter's mailing list message that outlines this proposal for X Server 1.8+ can be read on xorg-devel. As of right now there are no replies to his thread, but hopefully that will change and a version of this proposal will become policy for X.Org going into the future.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Rosewill RS-MI-01: An Ultra Low-Cost Mini-ITX Chassis
  2. D-Link DCS-2330L HD Wireless Network Camera
  3. Gigabyte AM1M-S2H
  4. AMD's New Athlon/Semprons Give Old Phenom CPUs A Big Run For The Money
Latest Linux Articles
  1. AMD Catalyst 14.4 Brings Few Linux Performance Improvements
  2. The Performance Of Fedora 20 Updated
  3. Clang Fights GCC On AMD's Athlon AM1 APU With Jaguar Cores
  4. Ubuntu 14.04 LTS vs. Oracle Linux vs. CentOS vs. openSUSE
Latest Linux News
  1. Valve Is Bringing VOGL To Windows & Working On Regression Tests
  2. Canonical Is Taking Over Linux 3.13 Kernel Maintenance
  3. Google Web Designer Is Now Natively Available On Linux
  4. Ubuntu 14.10 Is Codenamed The Utopic Unicorn
  5. Audacious 3.5 Lightweight Audio Player Released
  6. Steam Updated For Ubuntu 14.04 LTS, SteamOS
  7. DNF 0.5 Yum Replacement Now Supports Groups
  8. Red Hat Enterprise Linux 7.0 Is Looking Fantastic
  9. Intel Is Launching An Interesting Bay Trail NUC Next Week
  10. Another X.Org EVoC Proposed For OpenGL 4+ Tests
  11. The Best Features Coming With Qt 5.3
  12. Red Hat's RHEL7 RC ISO Is Now Publicly Available
Latest Forum Discussions
  1. The Most Amazing OpenGL Tech Demo In 64kb
  2. Announcing radeontop, a tool for viewing the GPU usage
  3. HTPC-upgrade advice: AMD Richland A8-7600 or Kaveri A10-6700T ???
  4. New card. Open source drivers only.
  5. The GNOME Foundation Is Running Short On Money
  6. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  7. Script for Fan Speed Control
  8. Torvalds Is Unconvinced By LTO'ing A Linux Kernel