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

openSUSE Has A Problem, Is Seeking New Direction

SUSE

Published on 14 June 2012 06:44 AM EDT
Written by Michael Larabel in SUSE
76 Comments

Stephan Kulow, the release manager for openSUSE, has publicly acknowledged this morning that this community distribution to SUSE has found itself in a problem and they're now looking to the community to seek out a fundamentally new direction for this Linux distribution.

A message hit the opensuse-factory mailing list this morning, written by Kulow, and entitled "Calling for a new openSUSE development model." I was alerted in advance to the pending announcement yesterday in an embargoed email entitled "openSUSE to do some soul searching after delay of release."

What it's come down to is that the openSUSE 12.2 development releases have seen major delays due to broken packages and other problems. Every milestone has been delayed and now today they're delaying the first release candidate as well as the final release. Because of these delays and limited manpower, they're seeking out something different to do. Yesterday's private email also expressed, "[Kulow] believe believes the cause of the delays is a result of changes in the openSUSE community lately. We've grown and our current way of working doesn't scale anymore."

In yesterday's advance email, "This is a combination of a wakup-call and an opportunity to find new directions. We need to start working differently - and as we've got tools like OBS and initiatives like Tumbleweed, we are uniquely equipped among the major Linux distributions to do something new and different. Let's see where the discussions bring us."

Among the expressed ideas they started off with were abandoning release schedules for openSUSE, pulling back to releasing on an annual basis, and/or moving to a pure rolling-release model built around openSUSE Tumbleweed. Below are some of the ideas Stephan expressed in his public email this morning.
1. We need to have more people that do the integration work - this partly means fixing build failures and partly debugging and fixing bugs that have unknown origin. Those will get maintainer power of all of factory devel projects, so they can actually work on packages that current maintainers are unable to.
2. We should work way more in pure staging projects and less in develop projects. Having apache in Apache and apache modules in Apache:Modules and ruby and rubygems in different projects may have appeared like a clever plan when set up, but it's a nightmare when it comes to factory development - an apache or ruby update are a pure game of luck. The same of course applies to all libraries - they never can have all their dependencies in one project. But this needs some kind of tooling support - but I'm willing to invest there, so we can more easily pick "green stacks". My goal (a pretty radical change to now) is a no-tolerance strategy about packages breaking other packages.
3. As working more strictly will require more time, I would like to either ditch release schedules all together or release only once a year and then rebase Tumbleweed - as already discussed in the RC1 thread.
A posting to be published in the next few hours on news.opensuse.org will lay out additional details and request for comments from the community about what future direction openSUSE should take.

What do you think openSUSE should do?

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. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  2. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
  3. AMD Radeon R9 285 Tonga Performance On Linux
  4. Apotop Wi-Copy
Latest Linux Articles
  1. AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver
  2. MSI: Update Your BIOS From The Linux Desktop
  3. NVIDIA vs. AMD 2D Linux Drivers: Catalyst Is Getting Quite Good At 2D
  4. 15-Way GPU Comparison With Mesa 10.3 + Linux 3.17
Latest Linux News
  1. Linux 3.18-rc1 Released One Week Early With Many Changes
  2. The VC4 Gallium3D Driver Is Still Moving Along For The Raspberry Pi
  3. Direct3D 9 Support Might Land Within Mainline Mesa 3D Drivers
  4. OpenGL Preview Benchmarks For NVIDIA's GeForce GTX 970
  5. HOPE: The Ease Of Python With The Speed Of C++
  6. Vitesse: Using LLVM To Speed Up Databases
  7. AMD Is Restructuring Again, Losing 7% Of Employees
  8. Linux Testing Of The NVIDIA GeForce GTX 970
  9. Qt 5.4 Now In Beta With Web, Bluetooth LE, Graphics Improvements
  10. AMD's Radeon R9 285 On Linux Offers Good OpenCL Performance
Latest Forum Discussions
  1. AMD Is Restructuring Again, Losing 7% Of Employees
  2. Bye bye BSD, Hello Linux: A Sys Admin's Story
  3. NVIDIA Presents Its Driver Plans To Support Mir/Wayland & KMS On Linux
  4. Open-Source AMD Fusion E-350 Support Takes A Dive
  5. Upgrade to Kaveri, very slow VDPAU performance
  6. ChromeOS Drops Support For EXT2/EXT3/EXT4 File-Systems
  7. Lennart Poettering On The Open-Source Community: A Sick Place To Be In
  8. The Slides Announcing The New "AMDGPU" Kernel Driver