openSUSE 12.2 release delayed, team calls for a rethink
Candidate's coding can't continue in current condition
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
The OpenSUSE community is engaged in an intense debate about the future of the project after the team announced that the 12.2 build won’t be ready for release on July 11 as scheduled.
"Pretty much every milestone of openSUSE 12.2 has been delayed or even canceled," said openSUSE community manager Jos Poortvliet in a blog post. "Compared to the preliminary schedule, milestones 1 to 3 were only about one to two weeks late – but milestone 4 had to be canceled and even Beta 1 was 2 weeks late. Release candidate 1 won’t make it either – to get Factory close to a releasable state we’d need to think about a serious delay."
The stability of the Factory distribution is not up to usual openSUSE standards, he said, and there are problems with the Buildservice development platform going down while churning through backlogs and the integration of features such as GNU Compiler Collection 4.7 and Automake.
With so many code snippets coming in, the Factory build is now broken more often than not, he said, and some developers need to look at the "bigger picture" of integration rather than just sending in poor code. Just throwing developers at the problems wasn't a solution to the problem, and now the entire organization of the project needs a rethink, he said.
The official statement was prompted by an email sent by openSUSE release manager Stephen "Coolo" Kulow that called for a rethink of the current system. Kulow outlined several areas of development that were broken, with Factory never having less than 100 major issues waiting for action and some projects lying fallow for months at a time due to lack of development work.
"It's time we realize delaying milestones is not a solution. Instead, let's use the delay of 12.2 as a reason to challenge our current development model and look at new ways. Rather than continue to delay milestones, let's rethink how we work," he wrote.
He suggested more code-staging projects for Factory and "a no-tolerance strategy about packages breaking other packages." The project should also consider either shifting to longer gaps between version releases, or just issuing them on an "as ready" basis like other open source projects.
The email sparked a huge debate, with the zypper team coming in for some serious criticism and proposals for making greater use of the Tumbleweed rolling release. No time limits have been set on making changes, but the community will face a major shift when they come.
"There's a challenge ahead for openSUSE, an interesting one at that," concluded Poortvliet. "What will we do? The discussion on the Factory mailing list is only now starting and we won’t have a decision any time soon. One thing is certain: the openSUSE 12.2 release won't see the light of day on July 11th but we'll come with something cool for the future!" ®
COMMENTS
train wrecks
It's good to know that the community can spot and avoid a train wreck before it happens.
Are you listening, W8 dev team?
Re: "The 12.1 release was so bad it was almost unusable on my netbook."
AFAIK, that whole update malarky was started by a particular club in Redmond who needed an argument to make people buy the same thing again and again. And when that didn't work anymore they created different looks to continue a sales cycle.
The clever bit was that they actually sold hope - hope that finally the platform had its bugs sorted, Naturally, that never happened until they made XP, which was OK enough for people to exit the upgrade game.
So that's where the update desire comes from..
Open Note to OpenSuSE...
Greetings and salutations;
I have been using SuSE distributions for quite some time now, and I am sorry to say that the 12.x distribution was almost enough to push me to Ubuntu. While the last maintenance release dealt with all the issues I had run into (for the mix of programs and features that I use), migrating from the 11.x releases to the 12.x release was a terribly painful and difficult process that added to the white hairs I have already.
There were several issues that caused me pain. First off, there were the various drivers and modules that did not work. While not a serious issue in most cases, it did mean that I was back to the generic, low functionality video and audio drivers. This caused some of the pivotal parts of the 12.x code to either fail, or work poorly. The the Plasma desktop, for example, was not a happy thing. Also, I had several more mysterious lock-ups that were hard to deal with. Then, there was the fact that a number of the programs I had been using either did not work, or, had changed so radically as to where they hid their work files it was easier to change programs than migrate to the new code. I am looking at you, Kmail, in specific. The audio issues were not pretty either, but after an update cycle or two, that stabilized. However, I had to bail out from using banshee to using VLC - which meant tracking down all the streaming audio sources I had in order to get them into VLC.
I would suggest these changes to the OpenSuSE development system:
1) For the moment, focus on quality of code, and, NOT on how quickly you can push out versions. Get it right first, then, push it out.
2) learn the difference between "this would be REALLY COOL" and "this makes the OS a better, stronger tool". Enforce those decisions for the "live" version.
3) It sounds to me as if some control has been lost over organizing code changes. Slow down the process a bit, and, have a pool of gurus look at proposed changes. Too many cooks spoil the broth. That does not mean that we cannot have a huge pool of contributors - just that there has to be some auditing by "big picture" folks.
I suspect I could come up with some more suggestions, but, trying to keep this to a reasonable length. In closing I want to say that these are presented purely in the spirit of helping OpenSuSE return to the solid, well-done distribution it used to be.
Pleasant Dreams
Dave Mundt
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Enabling efficient data center monitoring
