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. ROCCAT LUA: A Linux-Friendly Gaming Mouse
  2. Cheetah Mounts: The Affordable Way To Put Your TV On The Wall
  3. Scythe Mugen MAX
  4. Intel Core i7 5960X Haswell-E On Linux
Latest Linux Articles
  1. Preview: Radeon Gallium3D Performance For CS:GO On Linux
  2. XWayland Linux Gaming Performance With GNOME Wayland On Fedora 21
  3. EXT4/Btrfs/XFS/F2FS Benchmarks On Linux 3.17
  4. Fedora 21 Alpha First Impressions: It's Great
Latest Linux News
  1. Operating System U Fails To Live Up To Its Goals
  2. AMD Catalyst 14.9 Officially Released For Linux
  3. Nouveau Memory Re-Clocking Comes For More NVIDIA GPUs
  4. NVIDIA Suggests Explicit Synchronization For Nouveau
  5. Adobe Brings Streaming Photoshop To Chromebooks
  6. OverlayFS Proposed For The Linux 3.18 Kernel
  7. NVIDIA To Issue An Update On Their Support Of Mir & Wayland
  8. NVIDIA Is Still Working On The New Linux OpenGL ABI
  9. Intel Haswell HD Graphics With CS:GO On Linux
  10. The Most Dominating Linux Stories Of Q3'2014
Latest Forum Discussions
  1. New AMD Catalyst drivers out today
  2. NVIDIA Alerts Nouveau: They're Starting To Sign/Validate GPU Firmware Images
  3. Updated and Optimized Ubuntu Free Graphics Drivers
  4. Take the Steam Survey results with a grain of salt. It is flawed.
  5. FSF Issues Statement On Shellshock Bash Vulnerability
  6. AMD Wants To Know What's Wrong With Catalyst
  7. New Group Calls For Boycotting Systemd
  8. Counter-Strike: Global Offensive NVIDIA/AMD Benchmarks On Linux