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. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  2. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  3. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
  4. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
Latest Linux Articles
  1. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
  2. Testing For The Latest Linux Kernel Power Regression
  3. The Most Energy Efficient Radeon GPU For AMD Linux Gaming
  4. 20-Way Radeon Comparison With Open-Source Graphics For Steam On Linux Gaming
Latest Linux News
  1. Coreboot Adds Lenovo X220 With Native Sandy Bridge Support
  2. Canonical Has Yet To Land X.Org Server 1.16 For Ubuntu 14.10
  3. Imagination Launches A MIPS Development Board
  4. Getting Involved With The New Raspberry Pi Graphics Driver
  5. A New AMD Catalyst Linux Driver Unofficially Surfaces
  6. LibreOffice Ported To 64-bit ARM (AArch64)
  7. Enlightenment E19 RC3 Shows Off The New Wayland Compositor
  8. Metro Redux Is Going To Require OpenGL 4.x On Linux
  9. Jailhouse v0.1 Released As A Basic Hypervisor For Linux
  10. Google's Chromebook "Samus" Now Supported By Coreboot
Latest Forum Discussions
  1. Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs
  2. Catalyst 14.201.1008
  3. It's Now Possible To Play Netflix Natively On Linux Without Wine Plug-Ins
  4. Users defect to Linux as OpenBSD removes Lynx from base system
  5. Updated and Optimized Ubuntu Free Graphics Drivers
  6. Canonical Joined The Khronos Group To Help Mir/Wayland Drivers
  7. Radeon HD5670 and Ubuntu 14.04
  8. AMD Releases UVD Video Decode Support For R600 GPUs