Home Home > 2012 > 06 > 14 > Where is my 12.2, my Kingdom for a 12.2!
Sign up | Login

Where is my 12.2, my Kingdom for a 12.2!

June 14th, 2012 by

Failed geeko
Many people have noticed that the milestones and the Beta for this openSUSE release have been delayed or even canceled like Milestone 4. Now the RC is planned to go out Thursday – but that seems unlikely to happen as Factory, our development project, is still far too unstable. Coolo has send a mail to the openSUSE Factory mailing list noting that we need to re-think how we’re working.

We need new ideas

The mail by Coolo serves as a wakeup-call for openSUSE. Right now, we work via the devel projects which collaboratively send in better packages to Factory. But even then, sometimes things break in major ways and this breakage has gotten more frequent over time due to the growth of our community. One solution for this is to make heavier usage of ‘staging projects’ where packages get deeper testing and more integration can be done before moving to Factory. Another direction we could take is building more on our strengths like OBS and Tumbleweed. Slowing our release cycle to produce more stable releases say once a year, while increasing the emphasis on and efforts put in Tumbleweed and our OBS repo’s with newer software could give both ‘bleeding edge’ fans and those depending on a stable openSUSE more of what they want. Or, we go and loosen our release schedule, bringing out openSUSE ‘when it is ready’.

All options have pro’s and con’s. We want to avoid loosing ourselves: introducing rules and procedures to solve problems isn’t our way. So, we need fresh ideas and look in other directions. And now is the time to discuss these things: we’re bumping into the limits of how we work so the sense of urgency is there!

Limits: delays and cancellations

Pretty much every milestone of openSUSE 12.2 has been delayed or even canceled. Compared to the preliminairy 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.

Wazzup?

The milestones faced the usual issues. Sometimes, the Buildservice goes down – and with the huge amount of development going on there it takes a while for it to churn through its backlog and catch up again. Another issue were some problems with the integration of some of the bigger features – most notably GCC 4.7 but also Automake are still creating big pains. And in general, the stability of openSUSE Factory is not exactly up to our usual standards, as many threads in the Factory Mailing list Archive show.

Not incidents

But these integration issues are not just incidental but, according to release manager Coolo, exposing deeper problems. openSUSE contributions have grown in the last few years but the way we used to work doesn’t scale to our current size.

Broken windows

With more new contributors sending in bigger and small(er) improvements and quite a bit of plumbing going on in openSUSE, problems are arising. All these changes need to be combined, integrated, made a whole. Some people need to look at the big picture. This doesn’t happen at the rate it should be so things in Factory are broken more often than not. This leads to a bit of a broken-window problem: the more is broken, the less people care and the harder it is to get anything done – discouraging contributors. Say hello to a downward spiral.

All this has gotten us to the point where the release manager doesn’t feel confident that we can release openSUSE on time. Actually, Coolo says something needs to change if we are to do even remotely timely releases at all. Looks like a challenge!

Geeko is going somewhere  -awesome pic by cyberorg, click!

New Directions

We need to take the time to think about this and change things. The release will be delayed, that’s for sure. But how are we gonna tackle things in the future? As we’re grown too big for the current model, we have a great opportunity to find new ways.

Just more people won’t solve it. Especially things like bigger changes to the tool chain simply need a crew of highly experienced core hackers to fix issues all over within a reasonable time frame to avoid the ‘Broken Windows’. While we call on people to step up, we also need to look in other directions.

Release schedules and staging projects

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.

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.

openSUSE Factory workflow

Devel feeds Factory

Another step we might have to take is look closely at how we work. Working more in staging is what Coolo proposes. Working in the Devel projects is great but leads to integration issues. Working with more staging projects will need tooling support and won’t solve everything, but it is a step in the right direction.

A combination?

The solution might be found in any of the above directions – or all of them. 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!

Discussion

As a community project, openSUSE is led by people willing to take on a role where they make a difference. Those people are the ones who should chime in now and point in what direction we need to go. Coolo calls on everyone to

discuss things very openly – I think we learned enough about where the current model works and where it doesn’t so we can develop a new one together.

There’s a challenge ahead for openSUSE, an interesting one at that. 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!

Both comments and pings are currently closed.

143 Responses to “Where is my 12.2, my Kingdom for a 12.2!”

  1. Good day, i speak here as both an openSUSE user and as an openSUSE Romania contributor: i my opinion a combination of the ideas suggested in the article could lead to more instability. I strongly think that a new openSUSE release once a year its good but with better balance and testing between “new” and “stable” as attributes of the operating system that this community helps to build in different ways.

  2. Stephan van den Akker

    Speaking as a end-user I would very much welcome a slower release cycle. IMHO the present support period of 18 months is a bit too short for serious use. Generally, the quality of OpenSuSE software is good enough these days to skip versions. When this does not hold true the excellent OBS repositories provide newer versions.

    Tried Tumbleweed, but this proved to much of a hassle for me because of:
    - The re-base every 8 months;
    - The inability to support close source drivers;
    - The on-and-off availability of important software like LibreOffice.

    • @Stephan: yes, those things in Tumbleweed need improving. But that’s surely part of this proposal: make Tumbleweed more important, better. Not just a nice project but really a core openSUSE offering. That would include improving it significantly, among other things in the areas you mention…

      • Stephan van den Akker

        I think the discussions are ignoring the real strength of openSuSE: the OBS repositories.

        My openSuSE system at work is used by several colleagues. They log in over the company network to use Linux-only science and engineering software. Therefore I am rather conservative in updating stuff. I mostly just stick with the software versions that 11.4 brings.

        I use the OBS repositories to update the software when there is a need. In a lot of cases there is even the choice of “STABLE” and “UNSTABLE” repositories. As a bonus, when things don’t work, Yast gives me an easy option to roll back from UNSTABLE to STABLE to standard 11.4. I don’t see Tumbleweed ever providing that kind of flexibility.

        Whatever you change, don’t throw away the things that work well right now: OBS rules!

        • I think Stephen has hit the nail on the head. As an end user, who also has C++ and system admin background, I understand the need for both the unstable (i.e. Debian Sid) and stable distributions. The repository system works well, and lets you choose what level of danger you are comfortable with, and change that choice when it becomes inconvenient.

          I would argue that there need to be two levels of Sid (vicious and IceAge), where bleeding edge and soon to be frozen packages can reside. Conformance testing would only be done on packages making the transition from Vicious to IceAge.

          Rolling updates (ala Tumbleweed) are good for server based clients and lower maintenance (general users). Thinking of them like Service Packs for the well known commercial systems brings both their benefits and failings to the fore. OBS/repository provides a much finer granularity. Compliance/Conformance testing for Tumbleweed updates would be the most rigorous we can afford to do.

          In short, the current trials and tribulations are nothing more than the natural growth of the project. “The Mythical Man Month” showed that you can’t throw more people at the problem to change the date when the software will arrive. So if we can’t change the date when the new marvelous tools arrive, we can at least make that process as pleasant as possible for each type of user.

    • linux-padawan

      I fully agree with stephan, especially when talking about the support period. The current one is just to short.

      Also tried tumbleweed on my laptop, not really an serious option. Needs work e.g. support for x_64.

      Generally speaking, take you time to build quality, That will carry you farther than fast release cycles. ;-)

      Last but not least I would like to say. I have been using openSUSE every sice it was still SUSE Linux. I am very fond of it I would like to say a very big thanks to all involved. I appreciated the work you put into it.

  3. I generally agree with Stephan. A release cycle of “when it makes sense” sounds the best to me. Of course, more focus on Tumbleweed would be nice, too, but full releases are important due to the fact that they provide motivation for change. It’s a natural point for users to purge their systems and start anew, improved, without any leftovers from the old system (or aside from /home).

    • Ok, but do you need to re-start every 8 months? That’s a bit much – I re-install about once every 3 years, and I experiment quite a bit with unstable/weird stuff… So for a common user, once every 5 years (as in – new computer) should suffice. At least I think that’s what we should strive for. Even if you want to do it once a year, a one-year release cycle should be OK :D

      • Atilius

        I have to agree. My reinstall cycle is more than 3 years. At this moment I use 11.3 and maybe I will go to 12.2 but at this moment I dont have very serious reason to do it. I believe that there are many users like me.

        • Kon

          I tend to agree that a 1 year cycle makes sense, I too am an avid user, but reinstalls come every few years on my main systems. I am looking forward to helping with the process.

      • No, like I said, I’m all for releasing when it makes sense. Drop the deadlines and focus on releasing things when there are actually things to release, like a major DE and kernel update. That will probably mean longer time between releases, and I’m all for it. I’m just saying that going full rolling-release wouldn’t be as good as having actual releases.

        If you don’t reinstall often, then you’re really missing out. Every time after I do so, the desktop feels both more perfected and still very familiar. And faster, with less leftover configuration bugs. And each time there are new (small) problems with some part of it, but to me, these problems are in fact a driving force for reinstallation, as solving them gives me more practical insight into how each of the components work. So in the end, after each reinstall, I get a faster, having fewer bugs and more features desktop, and I learn something new about the system in the process.

      • OK, but you should also consider new users and new hardware support. if openSUSE releases every for example 3 years, nobody attract to migrate from other OSs to openSUSE, also it may not support new hardwares.

  4. Michael

    A release once per year in May or June would be best. Many software projects are now aligned to Ubuntu’s schedule, and adding one or two extra months would help stability.

    • Yes, we also discussed November/December, a while after the October releases of Fedora and Ubuntu. Or May/June, indeed.

      • Melvin

        I think much the same. Now a days I install a release and even before I have walked through it another one is out. May be yes, we should do less and and do it better. The apple way “less is better”. We could spend more time testing and integrating than creating releases.

        I believe the aim is to provide a friendly stable operating system which everybody could use. What I think is happening is that we are creating a product to experiment and test than to be used.

      • Maxim

        I think November/December would be great.

        • Melvin

          What about thinking of May/June/July? Developers could work at leisure during the summer vacations which comes around this time in most parts across the globe.

          • Maxim

            Release date is always come with big amount of preparation work needed to be done not only by developers but also by marketing team, testing team etc. I don’t think it’s much appreciated at summer vacation.

        • gumb

          It’s been suggested before to avoid releases that clash with the media frenzy surrounding Ubuntu and other competing distros’ own releases, around the April / October periods, though the counter-argument is that aligning releases is better for the scheduling of other co-operating projects and perhaps also provokes additional media coverage and publicity in providing opportunities for comparisons. Mid-summer and December are generally out of bounds due to developers’ vacations and other commitments. I would say late October / early November is good for another reason in that even beyond those who celebrate any end-of-year religious holidays, a good deal of users are travelling around this period and therefore have their best chance of the year to administer other machines and perform upgrades. It still allows enough leeway for a postponed release or for post-release problems to be ironed out.

          Consider also how will the openSUSE conference (normally likely to be held around September) fit in with an annual release? Such a conference serves many purposes, but if the releases were in October / November, the event could act in part as a media showcase of what’s coming, using the latest beta for demonstrations. On the other hand, with a spring release date, the autumn conference might serve better as a projection of what technologies are proposed as key or desirable for inclusion, giving developers a chance to discuss such things and get involved at an earlier stage long before any feature freeze.

  5. Ben

    The mistakes made by debian should be enough evidence against a “when it makes sense” release schedule.

    The speed at which software is updated and the desire by users to update with it will make opensuse even less popular if the release schedule is extended, and as a result opensuse will slowly disappear.

    Clearly there is not enough man power to keep up with demand, and developers and users are slowly being tempted away to other distributions like Linux Mint that have a strong support base and are constantly updated in one way or another.

    My advice would be to stick to a smart Tumbleweed release methodology that keeps in check things like 3rd party drivers. In other words, do not offer an update to the latest kernel or xorg if the NVIDIA/AMD driver does not support it! This will keep opensuse interesting and relevant.

    Also, opensuse must stop making so much work for itself. The only way to be successful and increase user base is to focus on a few key aspects. So, for instance, choose an official window manager and only focus on its stability, and keep it current. This is something that Ubuntu realized a while back with Unity. Personally i’m not a fan of Unity, but at least I know it is well supported and won’t bug out on me necessarily. This is really the problem since there is so much emotion built up for particular parts of opensuse, and no one is willing to do anything drastic or compromise.

    Personally I cannot stand KDE or Gnome3 on opensuse. KDE is bloated and Gnome3 is the complete opposite. Instead I suggest opensuse chooses a middle ground by either severely limiting the features of KDE, or releasing a more user friendly version of Gnome3.

    Limit what is supported and support those things well is the only solution.

    • You surely make some good points, Ben. Problem is that as a distro we currently focus on offering choice and catering to more computer-savvy users, not grandma. We can’t/don’t want to out-dumb-down Ubuntu and we can’t/don’t want to be more bleeeeeding edge than Fedora. So we attempt to build something more flexible and more stable than either of those for people who’ve got work to do.

      About the limiting the nr of desktops: IF we had the resources to do either of those really, REALLY well (like Ubuntu does, indeed), then I’d be all for it to de-emphasize the other one. But our resources are limited and due to the interests of our contributors pretty much equally split over the two. It simply doesn’t make sense to dump one for the other right now… We can’t tell people what to work on in their free time, after all. But again, IF a number of people would step up and manage to do something serious for either GNOME or KDE, we could do this, yes.

      Note that this is not that much related to our development model – the issues and choices we have there are of a rather different nature.

      • Ben

        First, ubuntu is not made for grandma any more than opensuse is made for professionals, because the fact is that anyone here can tailor any distribution to their own preference. Proclaiming opensuse as the distro of savvy users is meaningless.

        Second, it seems that there are many comments are made by people that are happy with older releases and desire stability above anything else. I agree that a stable bug-free release is necessary, but not at the cost of functionality. So, why not go for a smart Tumbleweed style rolling release schedule with stable releases every 2 or 3 years (e.g. LTS releases). This way, as someone mentioned above, problems can be tackled weekly rather than in an mass cluster-f*ck every 6, 8, or 12 months.

  6. Here’s an idea: Change the standard release cycle to 10 to 12 months, and issue a point release (eg. 12.2.1) midway through the release cycle updating the most commonly used packages (eg. common desktop applications like Amarok) with the latest known stable versions, while keeping the most basic packages (eg. GCC, glibc, kernel, etc) consistent with the original release (except for security updates, of course). A full release should update the system as a whole, including the kernel and other core components, tested for system-wide stability. This model is similar to Debian’s approach, but on a faster annual cycle rather than Debian’s two-year cycle.

  7. microchip

    +1 for release once a year. I share some viewpoints from the above posters so I don’t want to repeat what has been said already but I do think that once a year is the way to go.

  8. First, I’d like to say that there have already been some excellent points. The open source community tend to be rather passionate people–and such an issue is likely to cause strong opinions.

    One of the qualities of openSUSE that attracts me is the balance of stable releases with fairly current software. As an end user, neither the “release when ready” nor the rolling release models offer this balance for me. It’s for that reason that I would tend to lean towards a solution similar with what DragonLord suggested. Something akin to a semi-rolling release with a stable base, and an updated point release for applications, excluding the core components.

    I’m a big fan of KDE, and that was another quality that attracted me to openSUSE, but a streamlined “middle-ground” as suggested above might help consolidate resources and provide a sharper focus. Perhaps that’s easier said than done, however since the community probably would be pretty split as to what DE to focus on.

    At least there’s recognition that change is needed, and I’m glad that we can have an open discussion, where feedback is welcomed.

  9. Marcus Moeller

    Tumbleweed is a good starting point. Rolling releases are the future of Linux. Even Mark Shuttleworth is promoting an always usable testing branch.

    What I could imagine is a distro based on what we have right now and two paths:

    * security-only until next release
    * fully-rolling

    Fully-rolling would be where the music plays, packages are pushed in there from Factory as it’s the case with tumbleweed right now. After a year, a new ‘release’ is created which is exactly what last-release + fully-rolling updates is.

    So if one is on the fully-rolling branch there is no need to re-install, if one is on the security only branch, a dup or re-install has to be done. Otherwise the system will become unsupported, at least after two releases (which is 24 month in this case).

    Besides that I would split the packages in two categories: core and community. core is e.g. what is updated in tumbleweed right now (plus some additional packages), community could contain the extra packages that are harder to maintain.

  10. Eugene

    I fully support Ben here. There has to be a focus on a certain feature-set, especially when it comes to desktop offering. I see what Jos is saying about choice, but to be fair Linux desktops don’t stop at Gnome/KDE. There are also Enlightment, Xfce, LXDE etc. Concentrating on all and everything is simply not possible.

    And what Marcus says about concentrated/targeted releases makes a lot of sense.
    There also needs to be some sort of community run collaboration server (nothing fancy) but something to help the community stay constantly on top of everything that is going on.

  11. Matthias Welwarsky

    I’d never run a production desktop on a rolling release distro. Probably not even my own laptop at home. I’m pretty happy with the software I can download from software.opensuse.org, it has always suited me well when I needed a new version of a tool, like make, or cmake, wireshark, etc. Rolling releases are targeting only people who are, I’m afraid to say, not really doing anything with their machines but installing new software and timing if they boot faster or slower. Well, I may exaggerate a little, but you get what I’m talking about.

    My take: decide what is really necessary to be in the next release. Gcc 4.7.0 giving trouble? To hell, who runs a x.0 compiler anyway? New version of LibreOffice available but has major bugs? Let’s stay with the current thing. KDE 4.9 available but kmail fubar? Well, we may need to put some resources to iron out these bugs because it belongs to the core features of the release. Xorg Intel drivers broken again but we need the improved hardware coverage from upstream? Uh, maybe ask Egbert or whoever over a few beer to patch the stuff up.

    Just sucking in what comes from upstream, packaging and pushing to Factory is not eventually leading to a stable release (I know it’s not exactly what you’re doing). But really, your resources are not endless, and so your coverage can not be without limit. Contributors should be battling to be in a release, not you going begging on the bazaar.

    Think about it: You don’t need just more people. You need to ask yourself, and the contributors: why is an update worth being pulled into the release. What is the risk, what is the benefit. Don’t pull things in as a favor to the contributor, pull things because your users will clearly see the benefit.

    • I agree. Releases will always be needed – rolling doesn’t work for everyone, not by a long shot. We should get a tad more conservative and combined with having a slower release cycle we’d make even more solid, stable releases. At the same time, as the release is older, we’d need better OBS repo’s and Tumbleweed to get the newest stuff to our users

      • Stephan van den Akker

        Well said, Matthias.

        If participation in openSuSE is growing (good thing!!), then reorganise just enough to make it work. If it means putting people in a position where they can be a bit more selective about what is being merged, than that’s OK with me.

    • Maxim

      +1

      Yeah, Matthias, well said! I definitely agree with you.

  12. John CS

    I’m delighted that the need for a rethink has been identified. I try to keep up-to-date on releases as up to and including 11.4 more problems were fixed than were introduced. 12.1 was too unstable for my use even now. I have come from a MS development background and find KDE suits me well, and my wife now uses it. (I also run 11.4 KDE on an Asus Eee Pc 901 – not fast but fully functional.)

    It seems clear that there are users looking for a stable release whose priority is to have everything working and there are those who are looking for latest releases, and from other comments it appears a fair spectrum in between. But so far no one has raised the role of the Evergreen project. Where does that fit in this discussion, if it does?

    There is Tumbleweed, standard releases, and Evergreen. May be there is a need to split the standard release into a conservative branch with a longer support window and an adventurous branch? Perhaps the 12 series of releases have moved toward the adventurous side? Identifying the target user for a release (and publishing it) should let people pick that which will work for them.

    I greatly appreciate the work that goes into openSuSE so many thanks to all those who make it. And when I have mastered C++ and the Qt framework better I hope to be able to contribute something back.

    • Hi John,

      Thanks for your kind words. I’d suggest to come and visit the openSUSE conference in Prague or the openSUSE Summit in the US (Florida) – we can take care of that Qt/C++ knowledge for you ;-)

  13. Nir

    Hello There.
    i think that 12 months schedule release (and 24 mounths support) its better for stability and the developer team have more time to add there new technology/Software or new features to the opensuse release .

    i think that 6 months schedule like fedora and ubuntu team its too fast.and 6 months schedule release doesn’t mean better release

  14. My vote goes for an extended release cycle of 1 year, continuing with support for 2 previous version, which would ensure 3 year of support for each single version. I can only update my machines once a year in the summer anyway, and for more stable use cases, a 3 year cycle is reasonable.

  15. Dintch

    Hi there,

    I am a quite new OpenSuse user as I use it for my laptop since March and thus started with the 12.1 version.
    My vote would go to a one year release cycle as it would give time to develop (really) new and stable features and make a distrib that meets what OpenSuse is known for: to be a German distro with great stability, ideal for a productive environment.

    As you can see, I am looking for a stable distribution but like to get the new main softwares when the are ready, like Firefox, LibreOffice and so on, whilst I don’t really care of getting the edge-cutting new development library. There is a point to what Matthias said: getting newer versions is not just about fun, it is as well to get new and useful versions but first to get versions that are more stable. For instance, I moved to KDE 4.8 because it IS definitely better and more stable than the 4.7 version that comes with OpenSuse 12.1.

    Thus, I would suggest to make the OBS repositories a bit more responsive and to include the new KDE releases into that (as it usually brings a more stable environment). Then, a better-integrated Tumbleweed (that I use right now) could bring forward ALL the new packages, from Firefox to the deep-inside-non-understandable-for-everyone development library. Regarding the KDE into OBS, it could be suspended would a KDE release appear to be unstable…

    Last but not least, the desktop. I would say, for god sake, please do not fall into the Unity system. There are enough desktops and I thinkk we do not need to write a whole new shell. Providing users with KDE(OpenSuse recognized specialty) and Gnome is enough and let them use another one if they want.

    Hope it’s helpful and long life to OpenSuse !

  16. merlinux

    I liked the “combination proposal”!

    It does seems logic. I must confess i don’t like waiting a year for a new version, but from all the proposals this one seems to be the best.

    However, Tumbleweed really does needs improvements as Stephan van den Akker said at the beginning

    i would also “really suggest” for the stable version (the one-year-release-cycle version) that there should be an upgrade “a-la-ubuntu” to help people keep on easily whit the latest stable version.

    This are just my two cents! :)

  17. Paul

    I’ve only just started dabbling with OpenSUSE and in my opinion a yearly release cycle seems to be the best option.

    When it’s in beta it should go through lots and lots of testing, and not released until it’s very stable.

  18. Mike

    What I personally thing we need is a combination.

    1) We make a yearly release
    2) We split tumbleweed in a (kernel/xorg) stable/testing/factory version
    So people tumbleweed stable will have the normal 12.x base with a stable kernel so they can use prop. videodrivers/vmware and other stuff while using everything new declared stable. Testing would have kernel changes as well as some unstable packages slowly moving towards the next release, its basicly factory released on a point where it is considered reasonable stable.. Factory would just be factory and be broken all the time so we can test new stuff and fix it.

    My 2 cents.

  19. akaper

    All the reactions here are more or less handling the release cycle o about prioritizing packages for a new release. I’m “just” an end user, not a developer. But I think it also make sense to create a better infrastructure for the build-structure. Something that is more robust and future-ready (growing community and more building). Perhaps that should be step one and from there on we can better decide how to release?

  20. Tom

    One year release schedule for more stable & polished openSuSE – ideally synchronized month after new HW CPU/platform releases would be brilliant.

    Most people really need new and stable openSuSE for their new & shiny HW some time in late June/July with AMD/Intel desktop and CPU platforms.

    That was always the main openSuSE strength – it was stable and consistent on new and commodity HW.

    Productivity and media applications can be easily updated independently from OBS or build.

    Those rare remastered super-stable releases could be great model for low-is effort Christmas release.

    Extend support to 3.5 years – in return for fewer releases – this would be truly awesome – openSuSE going back to its polish and stability roots.

  21. Lars Norén

    I think a new, more mature, and more stable openSUSE release once a year is a very good idea. I use and promote openSUSE, but at the same time I usually say: “Download and install X.1 when X.2 is released, because by then X.1 is matured enough for a regular user.” That feels a bit awkward and contradictory.

  22. David

    I can wait for August for 12.2 – my only concern is that the Radeon bug that causes kernel panics is fixed. As of right now, my AMD X1400 GPU-based laptop is unusable using the RADEON KMS driver unless I use NOMODESET.

  23. “… one of scenario is to slow the release cycle a bit to one year releases …”
    I think it is completely wrong, you may ask why? i will tell you because:
    “Work expands to fill the time available for its completion”
    it is a law in time managemet called “Parkinson’s law”

    Parkinson’s Law means that if you give yourself a week to complete a two hour task, then (psychologically speaking) the task will increase in complexity and become more daunting so as to fill that week.
    OK, now in openSUSE case, if openSUSE team give them self one year to complete and introducing new verion, then this tast will take one year and at the end we will face with same delays as we face in 8 Months release priod.
    please see:
    1- http://www.lifehack.org/articles/productivity/how-to-use-parkinsons-law-to-your-advantage.html
    2- http://en.wikipedia.org/wiki/Parkinson%27s_law

    Best Regards
    Ali H Zadeh

    • Ali,

      You do have an excellent point. Indeed a yearly release in and of itself won’t solve our problem and we will have to keep this effect in mind. However, it would be just one step in a series of steps, and aside from the workload, there are other reasons why a one-year release cycle is a good fit for openSUSE…

    • targrava

      Good opinion, I’m agree with you too.

  24. Daniel

    Agree on the 12 month release schedule for fixed releases, there is always Tumbleweed and Buildservice for the more bleeding edge people.

    “We can’t/don’t want to out-dumb-down Ubuntu and we can’t/don’t want to be more bleeeeeding edge than Fedora.”

    This is one of the main reasons I run Opensuse instead of the others, so please stick to this policy :)

    • Daniel you are not the only one that likes this policy, i find openSUSE a good balance between old and bleeding edge :)

      • chika

        I’ve got to agree here. My testing of 12.1 was hardly what you might call a big success given some of the changes that occurred in relation to what I was trying to run. Indeed, my first upgrade attempt on one box with 11.4 on it was such a disaster that I had to roll back entirely, something that I have never had to do with an openSUSE installation of any kind before. A clean build on a virtual box worked reasonably well but left me questioning whether this really was an improvement; I currently have four 11.4 installs ranging from a netbook to a works server but after my experimenting with 12.1 I decided that I would only upgrade when I felt the need rather than be rushed into doing it because of an over-rigid upgrade cycle. I think I may have said something to that end back when the release/support schedule was changed last time.

        When I get a really good build (and I consider 11.4 to be just that), I don’t really want to shift from it unless there is a very good reason. 12.1 wasn’t a good reason IMHO, so if 12.2 needs more time to be put into reasonable operation, I can wait.

  25. Pjotr

    Agree on 12 month release schedule for fixed releases.

  26. I agree. A 12 month fixed release schedule would work great. Then, support must be offered for a minimum of 24 months, however, it would be really cool if support could be offered for 36 months or even 60 months. Lots of folks want stability and therefore desire to avoid upgrading the OS’s every cycle. After all, the OS upgrades don’t always work and then you are faced with a complete reinstall as was the case for me with my 11.4 upgrade to 12.1.

  27. tneo

    Once a year is more than enough for a new release. How about a BSD like system, where openSUSE puts together the base system, makes that stable and all the programs you want updated in repositories. This will focus more on stability of the system and users aren’t forced to constantly move to the newest release to get support. You would get a repository openSUSE base and openSUSE Gnome/ KDE (whatever). The openSUSE team focuses on the base system and the community will work with the software repositories. In the latter repositories aren’t linked to any version, but handle the latest software releases. In this there is the issue of dependencies, but it makes the core stable and lowers the need to release a new version.

    Keep the core of the system stable and let users easily update to new software if they want, but don’t force them to the newest release or having tons of repositories in Yast.

  28. Henne

    I also prefer the 12 month release cycle. To release as quick as it was in the past isn´t necessary any more. Most of the hardware is very well supported. So a new release should come if there are really new features coming up with and if they were bug free.

    openSUSE is for me the perfect balance between stability and evolution. Never give up the stability.

  29. hopeful

    We need frequent releases not so much because of latest OpenOffice or Firefox or gimp. These can be installed independently. Main issue is unsupported hardware. Release cycle of one year means that there will be a feature freeze about 6 months before. This results in current Linux release, which does not support any printer or tablet you can still buy in a shop. Installing third party drivers (network, graphics, wacom) continues to be a major pain in Linux, not siutable for regular users. So having a current Linux, which supports current hardware, is very important.

    I don’t think 8 month or 12 month or 24 month release cycle in itself will solve anything.
    I think the whole process is broken. A huge amount of work is repeated with each release, and lots of fixes accumulated for single release are thrown out of the window with each new release.
    Major releases should be dropped altogether, and replaced with rolling release. Replace single components within Linux and keep releasing it, for example, onece a week. In this way you can spread the problems thinner across longer period. Otherwise you have this huge spike of change on new release, which is always poorly tested and you need 4 months of accumulated patches to make it half useful. If a component change proves to be too disruptive, roll back the change and keep using the old one. This should be done with kmail, for example.

    • chika

      This happens to a certain extent anyway. Bugs are fixed, packages are updated regardless of the base installation, and that needs to continue. In fact, given the nature of the packages, whether it is an application or a driver, this can’t be avoided. This isn’t the same, however, as a complete upgrade of distro version.

      Drivers, I’m afraid, have always been a pain, no matter what the platform. It’s the biggest headache whenever there is a major structural change in the OS, Linux or not, and the stability of the underlying OS can often minimise the problem. However, it isn’t possible to completely remove the major upgrade cycle – hardware and software both evolve and a version can become unstable over time if you ask it to handle things it was never asked to do when it was being designed. Thankfully, the modular design of Linux minimises the worst of this, but it doesn’t stop the need to swap out major parts of the system every so often, for example when they change the way processors run or change the way in which drives are sectored.

      It comes back to how best to set out the plan for a distro’s future, whether it is about a rock-solid version that doesn’t get too adventurous, or a bleeding edge version that is more likely to give you problems if you don’t know what you are doing, or something in the middle. Up to now, openSUSE has given something for each scenario, and I believe that this latest move to question the user base is a positive step forward considering the problems that they appear to be facing.

      The length of the release cycle. What it needs is a realistic idea of how long it takes to produce a reasonably workable release. As for the length of any “feature freeze”, I suspect that “6 months” may be a figure based on current ratios, or could even be a figure plucked out of the air, but it’s something that may well need to be figured in with any change.

  30. vasu

    A slower “release” cycle ( once in 10 years is OK) , with updated packages well tested is probably the best thing for users. There is no reason for a) only “enterprise” versions to be LTS b) for LTS versions to have outdated, bug-ridden, back-ported packages like RHEL etc.

    It should be ALL LTS and updates should be current versions with fixes, well-tested. Best of all worlds, IMO. I do NOT care for changes such as wayland and systemd – things like that can be managed by developers themselves; users do NOT care. I do care about latest “stable” kernel, apache, KDE, xorg etc. Grub ? don’t care. systemd vs system V init ? Don’t care.

  31. gumb

    I have many points I could make on a range of factors so I’ll split them up, but the first is something that hasn’t yet been discussed here: Communication.

    Obviously this touches on your own primary role, Jos. I think one of the reasons for the ‘disconnect’ many openSUSE users may have felt in recent times is the lack of cohesive and visible communication beyond the bounds of the more hardcore developer community. One notable example is the openSUSE Weekly News which lost momentum. Personally I found it too much to digest on a weekly basis and perhaps overly technical in presentation, but the larger openSUSE community of regular users and fans needs to feel engaged and kept up to date with what’s going on around the project.

    I realise that this needs people to step up in the community (and no I unfortunately can’t commit myself at present). This is a bit of a vicious circle because probably a lot of people who’d like to help don’t know where to start and don’t have a clue about what is going on in the first instance, and where to source the information and from whom.

    Some kind of monthly newsletter, available online or delivered via email, perhaps with an overall more consumer friendly focus but including a technical devs section, could go a long way to getting people enthused again about openSUSE. I believe in particular there is a group of semi-active users in the community who like to read about progress with the next version of openSUSE and changes to Factory packages, etc., without having to delve through the factory mailing list or Git logs. There used to be pages on the wiki designed for this purpose but again it could have been presented better and easier to track.

    Another example of how things have lost momentum: I believe it may have been Will who opened or addressed a discussion in the mailing lists recently about the lack of communication. I used to casually follow the KDE meetings when minutes were provided. Again there is no obvious external communication anymore to people outside the developer community. I believe some medium of discussion needs to be found that is a sort of fusion of forums, wiki, IRC and blogs/newsletters, something interactive to allow the users better engagement with the devs and vice-versa, though I’m lost as to what that magic medium might be.

    And where is the input from the parent company, SUSE / Attachmate? In the Novell days, there was some degree of top-down command which may not be desirable in terms of having an independent community, but it perhaps provoked more communication and focused developers and other community members on where the project was going. Since the transition from Novell I think most regular openSUSE users have heard nothing from above. Even if they’re not interested in SLE they would perhaps appreciate more philosophical engagement in the way Ubuntu users get from people at Canonical. A few figureheads who at least inspire, though without having to dictate anything.

  32. robert

    I have been an end user since suse 9.2. I used 10.3 through its whole life cycle. As an end user I USE my computer. We need not buy into the idea of keeping up with other distro release plans. With that said we could take a lesson from Ubuntu. I think some sort of LTS (long term support) version would be welcome in the community. A fast release cycle does keep up with cutting edge software and is good. Please brothers, hear what 62 years of life has taught me “If it is not broken==do not fix it”

  33. robert

    Why not start with 12.1. Right here – right now. Make 12.1 better. In ancient times a soldier did not get a new sword with each use, He sharpened it and polished it and made it better.

  34. I agree with Robert about the need for some sort of LTS version especially since upgrades don’t seem to always work as was the case for me going from 11.4 to 12.1 where I ended up having to do a fresh install of 12.1. IMHO, Upgrades must work 100% of the time or OpenSUSE must have an LTS product or preferably, both.

  35. Daniel Lee

    I like the idea of Tumbleweed, but my experience with it has been generally negative, due to stability issues. But on the other hand I also understand the need for a release cycle for motivation. I like having the newest stable software installed on my machine. What if OpenSUSE were to go to a yearly release schedule and the current version would be a stable, working Tumbleweed?

  36. Hi !
    I’m agree about thinking in stability in first place.
    Let’s make things works properly. Let’s go step by step fixing problems.
    And at the end we will have a stable distro to be proud of it.

  37. Marius

    What if you would release every 3 years,support 5 years,or more,update the common used software from OBS and the specific repos!Works pretty well in windows(as an OS release I mean),like Windows 7 was released 3 years ago,and will still be supported for much longer!(I don’t know about the low level stuff like kernel,gcc,xorg and others,how it could be done,if a user would want to upgrade some of this stuff,you know for performance,new hardware,new fixed bugs,etc.)

  38. Well…

    I’m disappointed. I’ve been using Linux as my primary desktop for years, and one of the problems I run into is that the latest versions of some of the photography related applications require newer versions of KDE graphics libraries to work. So, if you want support to convert the raw files from the latest camera models via programs like digiKam, you need newer distributions. That tends to be a major issue for a number of distributions.

    As a result, I’ve been looking to distributions with a more frequent release schedule to fill in that gap. OpenSUSE was one distro I had hoped would do that, and I was looking forward to a sooner release. I found this page when I wondered why RC1 had not shown up on the mirrors yet.

    What’s the answer? I don’t know. But, perhaps trying to freeze earlier and not doing quite as much with a new version may be a better approach than trying to included “everything including the kitchen sink” into each new release.

    My main concern is that newer versions of applications be made available, without the “jumping through hoops” needed trying to use alternative repositories (tumbleweed, etc.), which can be confusing to more experienced linux users, much less newcomers to Linux that just want to use the latest version of digiKam, and similar applications.

  39. Nei

    The delay sounds sensible, the beta has so many problems I don’t even want to test it :-/ To be honest I was *shocked* when I thought to myself, beta1, maybe that is a point to chime in and help report the last remaining minor issues. Problem: issues are major. Just take the crash in software center as an example, how is one supposed to work with that.

    I hope there will be more polished and stable RCs and I can continue promoting openSUSE to my friends and colleagues as a modern yet stable system where all the components work well together! If 12.2 were released in that state it’d be a big disaster (even if many people won’t like to hear that)

    I’m a big fan of openSUSE but yet at the same time I want to have a stable system that just *works* and where I don’t have to tinker around. I also want my family members to be able to use it comfortably. So far 11.4 is doing this job fine for me, and 11.2 was before that. The new 12.2 (beta) scared the hell out of me. I guess things can only get better.

    Nevertheless a big thanks to everyone involved for the hard work and making openSUSE a good product! And don’t let the delay drag you down. Given the current state it seems like the right choice for us users, too.

  40. Andrwe

    Since there is a delay, why not wait for KDE 4.9 to be released so openSUSE 12.2 will be cutting edge :). The Linux kernel 3.5r2 is current and should be available by the new release date so this should be included.

  41. I’ve given some additional thought into this, and so far this is what I believe would be ideal:

    - Make the deadlines less meaningful. That is, don’t have a 6 month release cycle, nor a 9 month release cycle, nor a 12 month release cycle. Instead, have a 9-12 month release cycle. In essence, keep the current way of releasing things – plan for all the features to be there in 9 months – and if they are, do make a release – but if there are major problems, then take the time to work on solving them. Three months should be enough to iron out any problems, or revert to something more stable if it doesn’t work.

    There are several reasons for a proposal like this. First of all, having a yearly release, as it was already mentioned here, wouldn’t really solve anything. A deadline is still a deadline, and developers would simply start working on it later, and still wouldn’t meet the deadlines, therefore nothing would change. Besides, one year is a really long time in terms of software development. There are multiple kernel releases supporting multiple new devices and vastly improving support for others even with the current release schedule, and just making it longer would not only not solve any problems, but even introduce new ones. After all, we already have one Debian, we don’t need two, and openSUSE has always been a distribution that had something for everyone.

    Alternatively, here’s another idea that I’d find pretty acceptable:

    - Expand on Tumbleweed and make it the primary form of openSUSE, but don’t drop releases, either. However, make releases in the form of snapshots. Those snapshots should not be weekly snapshots (mind you, a daily snapshot service, like Ubuntu has, that would work on SUSE Studio would be awesome, but it should be an addition, not a replacement to regular releases). Instead, the release snapshots should also come only once or twice a year, and should not be latest snapshots when they are released. Basically, have stable and proven snapshots as releases every 9-12 months. These snapshots then could be eligible for the Evergreen status and extended support.

    This way, people who prefer stable software and long term support would get that in the form of release snapshots, while those who like to be on the bleeding edge would use Tumbleweed. That said, since I don’t think that has been attempted before, I’m not sure what kind of problems you could run into when using a scheme like that, but it does seem like there would be less problems with release scheduling that way.

    Either way, integrating Tumbeweed into SUSE Studio and creating Tumbleweed stable and unstable branches seems to be a good idea all around, regardless of which release scheduling type is picked.

  42. How about taking a good stable release e.g.11.4, and turning it into an Ubuntu style LTS?

    Development of 12.2 could still go ahead but we are seen to be doing something meanwhile.

    • metalized

      This is an excellent idea. I use openSuSE on my business laptop, and moved from 11.3 to 114, when 11.3 was eol’d.

      It would be essential for me to know that I have a stable release I can depend on for my business, when at the same time, I have updated packages; not necessarily bleeding edge, as they need to be stable, so an LTS release is a really good idea and as I am currently happy with 11.4, I would love it if it got LTS’d.

    • Except that it already is. 11.4 is supported as Evergreen until May 2014.

  43. Marius

    Please don’t copy Ubuntu!There is nothing there besides snapshoting Debian unstable,jokey,some ppa’s,much hype and many bugs!

  44. Marius

    I meant “jockey”!

  45. metalized

    From all the responses here, it is obvious that a yearly release cycle would be the way to go.

    From an end user perspective, such as I am, I would say that it would be essential to focus on stability. I will mention only stability, because what is important for me is to have the system running when I need to. I need it to run in a stable fashion. I does not mean a lot to me if I have libreoffice 6.7.8 if I cannot use it, the way I am using now 3.5.3. Yes, true is that I was looking forward to a stable 3.5.1 libreoffice, as I am looking forward to a stable and faster kde 4.9. But I will not update, just for the sake for updating.

    I have not yet tested tumbleweed, so I cannot say anything about that.

    Of course there is the need to attract new users. It will be more difficult I suppose to attract someone who wants to use Linux for the first time and sees that Fedora has KDE4.9 where as openSUSE is left behind at 4.8.

    This is all theorizing, but the way I see things as well. I would like to take tumbleweed on a test drive and see how it will work out for me.

    Ending, let me thank you all for the great work and congratulate you on this excellent OS. Keep up the good work, as I am sure you will!

  46. xman

    As an end user, I prefer OpenSUSE’s team take the time you need, and in the end is a quality product. While some users are going to prefer the latest versions of KDE, Gnome etc, the reality will be that the more stable will be the most preferred. A greeting and thanks to all those who in one way or another, they make OpenSUSE xxx, is an excellent distro.

  47. The strength of Linux is freedom to choose! We need Tumbleweedet opensuse and one high-config zypper updater (I mean of alternate Apper that really work directly with zypper). So that anyone can choose their level of stability and functionality.

  48. As some people mentioned here, i suggest following actions to make openSUSE more attractive:
    1- increase release period to 1 year (instead of 8 months). this will allow developers to do their work with more peace BUT you should be care about “Parkinson’s law” too.
    2- only focus in one desktop. before i became an openSUSE user, most of people advised me “if you want test KDE, only use kde in openSUSE” they told me KDE work better in openSUSE than other distroes and in the other hand openSUSE work better with KDE than other desktops. So openSUSE team should focus on one DE, and i think best DE for openSUSE is KDE.
    you may say: we cannot forced developers to do something they don’t like; yes, you cannot, and you may loose some developers also but in the other hand the remaining developers will have more time and less workload; and also focusing on only one DE will attract some other developers that like this strategy too. and at the end openSUSE project wil be the winner.

  49. Sayth aka flebber

    I would like to approach this positively and not with fear. No one model is ever going to be 100% right, rolling release are not unstable or dangerous unless of course your on “sid” and timed releases never make sense either.

    I would propose a more semi rolling release with stalled updates(service packs for lack of a better term). I think openSuse should release when ready within reason, the reality of debain in that respect is that does take too long to release.

    ** My key point is that openSuse should release when we are ready, when openSuse has new features or updates or a significantly better GCC/system.d/kernel is released. We shouldn’t release just for desktops why should a full reinstall of opensuse occur at 8 months when the only significant upgrade is KDE or Gnome? In my book we should releive the release team of this burden and allow more budget(time) to cool innovate projects and overall stabilisation. A method for releasing collective updates(KDE/GNOME/XFCE/E17/fwm) as updates to the current distro; staged; rather than backports would be preferred by me.

    Solid updates to the core distro; Solid releases when ready.

  50. Alex

    What a disasster, this is not a professional behaviour for a serious linux distro.
    I need a uptodate and stable distro!!!!

    • gumb

      In that case you might be better off with SLE, a professional / enterprise level distro with corporate financial backing. openSUSE is ultimately a community project and has no commitments to meet to anybody in particular in terms of release punctuality, stability, appropriateness, update frequency, etc. It’s a shame when something like this happens, but better it is openly discussed and the chance taken to reassess the best way forward for the distro, than to rush through an unstable release or, as often happens with other distros, keep putting back the release date indefinitely leaving users with no clue what’s going on.

      If you need an up-to-date distro, the current version of openSUSE 12.1 is effectively up-to-date, but if you mean as in cutting edge packages, you’re not likely to then satisfy your second demand of stability.

      • Moz

        “If you need an up-to-date distro, the current version of openSUSE 12.1 is effectively up-to-date, but if you mean as in cutting edge packages, you’re not likely to then satisfy your second demand of stability.”

        Opensuse is neither up to date, nor stable.

        An obvious example of unstable is the current amarok/mysql debacle. Of course, the dim bulb devs working on amarok should never have moved to mysql, but that is a different issue.

        There are too many packages in 12.1 that are 12+ months behind the current stable releases to list, making your argument about 12.1 being up to date laughable