openSUSE team has announced that RC of openSUSE 12.2 which was scheduled to be released today is not going to happen as Factory, their development project, is still far too unstable. This has affected the release of openSUSE 12.2 which was scheduled to be released in July. openSUSE 12.2 is now expected to be released in mid-september.
openSUSE seems to be going through some challenging times. In the last two-three months, their servers failed couple of times, leaving users machines without access to repos. I am an openSUSE user (multi booting with Ubuntu, Fedora and openSUSE) and I was affected by it when I was travelling and could not install the apps that I needed at that moment. Luckily I had another distro on that machine which saved my life.
The good news is, openSUSE team is seriously looking at these problems and re-thinking how they work.
Stephan Kulow (aka Coolo), the release manager of openSUSE sent out a mail calling for a new development model. He pointed at the problem openSUSE teams are facing:
openSUSE has grown. We have many interdependent packages in Factory. The problems are usually not in the packages touched, so the package updates work. What’s often missing though is the work to fix the other packages that rely on the updated package. We need to do a better job making sure bugs caused by updates of “random packages” generate a working system. Very fortunately we have an increasing number of contributors that update versions or fix bugs in packages, but lately, the end result has been getting worse, not better. And IMO it’s because we can’t keep up in the current model.
Jos Poortvliet, the community manager of openSUSE believes, “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.”
He added that, “One issue is that more attention should be devoted to integration of changes. For that we’ll have to explore other ways of working like using staging projects. Moreover, with Tumbleweed getting more popular we could consider changing our release schedule as well.”
There are several possibilities — either to adopt a Debian model (release when ready) or a rolling release model or change the way openSUSE team works.
Jos says, “We could drop the fixed release schedule and release ‘when ready’. But this could lead to long freezes (a la Debian), uncertainty for the users and either out of date packages or huge discrepancies in quality.”
How about making openSUSE a rolling release like Chrome or Arch? Coolo says that “giving up on releases altogether, making openSUSE a tumbleweed-on-SLE would work as well. But – to mention just one issue with this scheme, Tumbleweed needs to rebase on new releases as it’s not designed to roll forever. So it would depend on new SLE releases for major plumbing work which, in effect, simply moves the problem to SUSE.”
Jos says that a possible scenario is to “slow the release cycle a bit to one year releases (probably somewhere in April) and become even more conservative with those: the releases would contain changes, but only well-tested and stable new technologies would make it in. Meanwhile, we’d emphasize Tumbleweed and the OBS repositories more as the way of getting the latest and greatest of what Free Software has to offer. We’d also have to change how we work, introduce the staging projects, maybe improve certain parts of the OBS workflow. For end users, we might possibly release ‘snapshots’ of Tumbleweed or experiment with what we could offer through SUSE Studio.”
“If it works, this scheme would mean a lower workload for the release team and more choice for our end users: more stable (the release) and more up-to-date (tumbleweed). Like all major changes, it’s risky and requires quite some thought on the details. But the end result could be a better, even cooler openSUSE!” concludes Jos.