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. pmller

    Horrible news, indeed. In my opinion openSUSE should concentrate on a stable release once a year and support it for two years. For users who wish to use bleeding-edge software Tumbleweed will be the right choice.

    But I suggest to incorporate even openSUSE 12.1 into this new release model: Extend the support time frame for openSUSE 12.1 to two years and release a rock-stable openSUSE 12.2 (or 13.1 or whatever) in November 2012.

    The lack of communication is also well-known. Sometimes e.g. oldcpu feels that there is a lot of unknown information which is very important for the openSUSE community and then he starts to write something like “What happened at the openSUSE mailing-lists” for the openSUSE forums to inform “normal” users about the new direction of xorg development in openSUSE 12.2, for example. This is something that must be done more often by the communication department or by Suse “insiders”. Moreover, more expert input by Suse is also needed, not only on the mailing-lists, but in the openSUSE forums, e.g. when users report critical xorg driver problems.

    Let me give one example:
    This bugreport
    https://bugzilla.novell.com/show_bug.cgi?id=756962
    indicates that openSUSE developers actively care about the security of non-free Nvidia drivers which are offered for maintained openSUSE distributions. This is something that should be reported on the forums. There are many Linux users outwhere who do not know this level of support and think that openSUSE/Suse does not care about “external” Yast repos.

    • Arturi

      I concur with pmller. 18 months release cycle is just too rapid and overambitious without giving benefit to anybody. Stick to an LTS mode (or 2 years or 30 months cycle) and you’d be better off (more proper maintenance, less hassle, less buggy release, giving more time to grow user base, etc)

  2. fishermans friend

    What happens if fixed release cycle is skipped? instead release something whenever there seem to exist a good (stable/new) combination of its components that feels (subjective of course) like an upgrade from the previous release? Until tumbleweed doesn’t require the re-base, if that happens.

    Suse is very appreciated, so if the release takes more weeks, months to complete and the result is better in comparison to stressing a release now to meet the road map date, I’d hope for that. :)

    Regards

  3. Isidro

    I’m also still on 11.3 and lovin’ it, except I can’t find a mirror with the old repos. Help anybody?

  4. Joseph Gornall

    Hi, just downloaded and installed 12.2 64 bit, Great! It runs smooth and fast on my AMD Processor (CPU): AMD Athlon(tm) Neo X2 Dual Core Processor L335
    Speed: 800.00 MHz
    Cores: 2
    which frankly nothing else will in 64 bit, the graphics are working a treat and it seems pretty stable to me. It must be hard work (I can’t code stuff) but I, for one, really appreciate all the effort. Good luck with everything.
    Regards,
    joseph

  5. allgoodnamesaretaken

    I would also prefer the longer release cycle for rocksolid, stable release, like 1 or 1.5 years. Where needed, newer software could then be installed individually via repos and/or a tumbleweed. But the longer release cycle should combined with a longer lifecycle like 2.5 to 3.5 years in which (at least security) updates are provided. This would perhaps result in opensuse beeing a reliable, stable linux distribution again which I missed since 11.0…

    However, thans for all your efforts people! :-)

  6. Candido Fontes

    I am waiting to have the official openSuse release… Since 2009 I try to use this distro and must say that it was the one that make me believe in Linux. But now I have some hardware problems (ATI drivers) on my laptop, witch make me try others distros to get best performance. As I have heard that openSUSE is quick and nice, the truth is that for me has always been very beautiful. In spite of not understanding anything about linux, openSuse is a distro that is very helpful when setting up and customizing. The question I would like to ask is: Why not make a distro that can be updated automatically, independently of the version? Would have a problem? If this is the case with Tumbleweed, what is the difference between a Tumbleweed recently updated and a opeSuse recently released? Thanks all for sharing your knowledge and results. Forgive my English (…never was good at school!)

  7. Anonymous

    I would prefer stability and security over the latest grapgical do-da. Since you support so much, and that is great, perhaps more time building n instance would be a truly good thing i for everyone. If nothing else for you so you don’t feel rushed to get it out. Trust me, everyone prefers to wait for something good instead of getting a so-so distro.
    I don’t nearly enough of your process but I’ll happy wait a year while you figure out how to make it work for you and then get a excellent edition, like I’ve grown used to.

  8. Sayth

    I think the forgotten point sometimes is that if we forget about releasing often and instead focus on stability, security and ingenuity there will be far more benefit.

    Time can be directed to more community projects that result in better tooling and more fun overall. Eg Yast is great but could use a little love; not a lot cause She is nice how she is; rather than the standard desktop updates.

    If a solid backports system is setup there will seldom be need for distro updates every 6-8months.

    Importantly however the should be a clear charter or directive that defines when a release should occur. What criteria are key? When is the tipping point that a new distro should be released? is the weight/amount of updates to the distro or the importance of the updtes eg improves stability/security to a wide range of packages Xorg/GCC etc.

    Question if a distro is release with say python 2.7 and perl5.12 if both these had significant updates to say 3.3 and 5.16 respectively would that force a whole distro update to upgrade them>

  9. Dragonbite

    A lot of good comments here. Mind if I add my own? OpenSUSE’s dedication on things like video cards is part of what attracted me. I found my video being supported earlier than other distributions even if it weren’t “perfect”, and while other distributions are writing it off, openSUSE 12.1 worked as close to perfect as anything ever! So quality of the work is an asset openSUSE needs to maintain.

    I am liking the sounds of the “3-prong” approach; longer release cycle, increased OBS for “bleeding edge” and Tumbleweed for long-term-support.

    [ Longer release cycle ]

    A longer release cycle for the full freeze-build-test-release would hopefully get a strong and stable platform and that doesn’t remove security updates or package updates.

    [ Point releases ]

    It also could include a point release that rolls up newer common packages into a stable environment positioned so the full Life Cycle of the release is cut evenly 2 or 3 times. If a package is not available or stable enough for N.1, then it provides time to make N.2, both largely built off of the original N.

    An 18 month release cycle with 2 point releases would provide 6 months for testing and building on the release that doesn’t change for a year and a half. A 2-year release cycle with 2 point releases would be 8 months each.

    Could this provide the longer stability without maintaining aged packages?

    [ Tumbleweed ]

    Security updates could continue for another 12 months while Tumbleweed takes over the package version updates.

    [ OBS ]

    The OBS would help in providing “bleeding edge” in-between releases and a testing ground that could get rolled up into point-releases since the foundation would not be changing as quickly.

    Could this help balance the need for newer packages and to help facilitate development for future releases?

    [ Future ]

    It seems that the computing landscape itself is changing rapidly and openSUSE does need to be able to address these issues (e.g. such as UEFI, updated mobile devices (tablets, new smartphones), web trends (Facebook, whatever comes next), etc.).

    Having a set freeze and release, I think, isn’t going to harm things, when there is the opportunity to aim for a point-release knowing that the underpinnings are not changing.

    These are just my ideas, do with them what you will.

  10. SB

    I use and depend on OpenSuSE Linux in my work. What I would like, is
    longer support periods and more quality. I do not need a fast release cycle.

    For example, I still use KDE3 because I have found it more efficient and reliable to use than KDE4 and Gnome.

    The main advantage with Microsoft Windows is its stability (it doesn’t change fast) and very long support periods (about 10 years for Windows XP).

    Thank you, you who develop OpenSuSE for all your work.

  11. I think a 1 year release cycle and 3 years support (lifecycle) is excelent for openSUSE.
    also i want openSUSE developers to do not try to satisfy enybody with expanding their works, they should try to focus in some aspects for example focus only in one DE (that is KDE).
    Thanks

    • gumb

      I don’t agree with focusing on one sole desktop. I’m primarily a KDE user but I wouldn’t want it to be the only desktop given attention. The flexibility of openSUSE means that I can deploy very different setups with different DE’s according to needs, for example sticking XFCE on a older, slow machine, but still have YaST as an underlying configuration tool and not have to follow multiple sources for news / updates / support etc.

      There seem to be several hundred-and-one distros springing up these days that take an existing distro and then change the DE, there’s almost a new one every day. If somebody really wants an openSUSE KDE or GNOME spin, for example, they can either use the Live CD version, employ SUSE Studio or take a bare base install and add the bits they want. openSUSE’s ‘something for everyone’ philosophy might well make it a bit heavy on install size and not the snappiest machine around, but the trade-off and strength over so many of today’s single-DE distros is exactly that versatility.

      • But you should consider that opensuse is a communiy driven project, So opensuse developers may do not have enogh time and resources to provide an complete, stable, up-to-date and excelent distro with many DEs such as KDE, Gnome, XFCE, LXDE, …
        in current situation, they shuld concentrate their efforts, i think.

        And …

        Another good suggestion could be Cooperation between openSUSE and some other similar distros such as Mandriva, mageia.

        • Pierre

          I think you’re not right, not wrong.
          In some way it is a good idea to concentrate on one DE, on the other not sticking to only one DE is one of the big advantages of openSUSE.
          Ubuntu needs different spins, the same with Fedora. And I really appreciate the openSUSE-way and hope that they succeed in keeping this freedom of choice.
          But as I posted down below, I think it is no bad idea, to focus more on KDE than on the other DEs.

      • Pierre

        I agree with you.
        OpenSUSEs strength is, that it does not concentrate too much on only one DE. So I am able to give everyone the DE that fits his/her needs more than others without the need of going to any other spin-off-distro that maybe even breaks some elementary points on openSUSE.

        Nevertheless I’m fine with a focus on KDE for instance. It is important to make a choice for reasons of identity and a single bit of unity. Everyone can make a choice at install time without being forced to go with KDE, but openSUSE has a face that everyone can identify as being openSUSE.

        Greetings and best wishes.

  12. Douglas Hinds

    “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.”

    That’s it. That makes perfect sense and should work out fine. Yearly releases, as stable and as rolling as possible. Don’t worry any further about it, just do it. We can wait.

    • Pierre

      You name it. :)
      And many others, too.
      So hopefully the developers listen to us. I just keep saying:
      I’d like to see an openSUSE that fits in the gap between Debian and Ubuntu. Rock solid and more stable than Ubuntu, but nevertheless more up-to-date than Debian.
      :)

  13. Marcin G.

    One year release cycle would be perfect form me, I dream about this since 11.2! More time to stabilize distro and less software to maintain for developers. Bring it on!

  14. Claude

    I would prioritize stability and quality over frequency of release. I would be perfectly fine with a 12 to 18 month release cycle, but mre important to me would be the number of open issues in a released version (i.e. only release if the number of issues is no larger than pre-defined numbers). In addition, the support time should be such that a user could skip 1 release without running into trouble, i.e., having a 24+/36+ months support window.

  15. Thomas Naser

    I too am fine with a 12 to 18 month releases cycle.

    I’m asking: WHY do you the Linux user NEED a new release twice a year? I’m not talking about bug fixes, security patches, and the like, but the basic, for lack of a better word, look to your favorite release?

    I have been using Linux since the early sixties and usually wait for two releases and install the prior one (ie. I have Ver.1 installed, wait until Ver.3 is released and install Ver.2) as in most cases there are major screw ups with something major and that I need and this usually lets me keep my computer working.

    I realize that the programmers can’t alpha/beta test on every environment but…

    • Sean Boyd

      @Thomas Naser,

      I’m impressed that you’ve been using Linux for 30+ years longer than it has existed.

  16. Why openSUSE developers do not try to cooperate with Mandriva and Mageia developers?
    these distros have many similar aspects and to some extend similar strategy, they could cooperate with each other and reenforce each other. i do not mean that for example Mandriva developers withdraw their distro and join openSUSE project but i mean they could cooperate with each other such as cooperation between companies in industrial Area; for example cooperation between KIA and Hyundai, if you look at this two company products you will see many of their products are alike and they only change the LOGO on the car.

    • kilfinge

      I agree with you. Nowadays, when so called big linux community is starting to be more and more divided, scattered, when there are appearing so many new distributions, and so many resources are focused on so many different little projects, it would made a real difference when big distributions would start cooperating together. Focus resources on advanced tools, and projects, which would offer something more to the end user. And the most important integrate aspects of the operating system which should be homogeneous for all distributions.

      Apart from this I also prefer strongly to see longer release cycle and lifecycle. This have some advantages:
      – More advanced users will find a time during longer release cycle to install and test milestones. This is especially important because most of end users which want to somehow support linux, usually use his laptops, desktops with linux for daily use, for normal work, and want to separate testing environment and stable system. Installation and testing is best on real hardware. So it takes time, and so it is better to do it once a year, and do it properly and give some feedback, than not have time for this because of other duties.
      – Less amount of stupid inconveniences or small bugs in the end of longer development cycle.
      – If the target user for opensuse is not only bleeding-edge maniac, which reinstall system once every 6 months, just to have the latest software, but the target users is also end-user which appreciates some kind of long lasting stability of the system for his daily work, we should go for it. For such kind end-user, re-installation of the system is justified only when this new piece of software will give him a real difference in work comparing to previous release. And this is not possible to achieve when release cycle is too short.

      In my opinion the release cycle should not be fixed to stringent and should vary over the time. It should be a function (with some limiting range of course) of the goals to achieve during the development. Sometimes they are less ambitious some times more, so are more time consuming.
      It should be also function of system completeness. For example, when kde 4 was introduced, I often reinstalled system, and short life cycle was better for me because there was lack of some functionality. At present I dont need that, I am happy because the basis is rather complete I can do may work on computer. Thats the moment I believe in which developers could focus on some new projects or some new ideas.

      But nevertheless, OpenSUSE it is best distribution for me, and thank you for your really hard work.

  17. Cae

    First few distro listed in distrowatch :
    – Mint
    – Ubuntu
    – Fedora
    – Mageia
    – Debian
    – openSUSE

    and my over-generalization of their targeted users:

    Mint – new users enjoying the ease of use
    Ubuntu – new users mostly likes the bling and reinstall every 6 months
    Fedora – bleeding edge users
    Mageia – ease of use, intermediate/experience users?
    Debian – stable, experience users who pulls from backports for newer stuff
    Debian – testing branch, intermediate users ..
    Debian – unstable branch, experience users enjoying bleeding edge stuff

    openSUSE – the important question is what does openSUSE wants their user to be?

    I suspect genuine openSUSE users don’t care really if it releases in 6, 8 or 12 months. Important thing is that it is secure, stable and updated with new enough programs.

    • Pierre

      I was using openSUSE because of the great power of Yast2 and delivering the most appealing command line package manager Zypper.
      I’m not using it at the moment because it is lacking on stability, the package base is quite limited (compared to the monster mass of packages in Debian).

      I would come back to openSUSE if it would become stable enought again without forgetting about up-to-date enough packages and I only can keep saying: I’d like to see an openSUSE that fits in the gap between Debian and Ubuntu. Rock solid and more stable than Ubuntu, but nevertheless more up-to-date than Debian.

      In which way that is achieved does not count to me as long as I’m just the user, because for me just counts that it just works!
      This was the reason for me using openSUSE, and because this is not the fact in the last releases, I was switching to Debian stable and testing, although I’d love to come back. But for that it would be like in the days of KDE 3.5 when everything was just working. :)

      Greetings and best wishes.

  18. I think OpenSuSE is pretty damn good and a mix between long term freezing and insane releasing…I vote for a fine wine, tasted by many and then distributed. Don’t be like redhat and allow the community to debug all your stuff but also don’t be line debian and afraid of the new things either. Its a balancing act and one which will be doable if you listen to the beta testers and get a real sense and focus; otherwise it will be longer than a year before I check again :)

    OK, see ya 2013 ;)

    • Pierre

      Yeah, as I already posted: I’d like to see an openSUSE that fits in the gap between Debian and Ubuntu. Rock solid and more stable than Ubuntu, but nevertheless more up-to-date than Debian.

      This would be – in my opinion – THE killer distro. I’m missing such a distro. I’m not fully happy with Debian because it’s outdated – but what I’m using at the moment because of missing alternatives – and openSUSE has not been stable enough for me in the close past.

      Great respect though to the community that they are not afraid of re-thinking the ways its going.

  19. Pierre

    I really appreciate the idea of slowing done the release circle to one year for a more stable release. I’d like to see an openSUSE that fits in the gap between Debian and Ubuntu. Rock solid and more stable than Ubuntu, but nevertheless more up-to-date than Debian.
    If the openSUSE community would succeed in doing so, I would be the fist one coming back to my openSUSE and embracing it like my own child.

    OpenSUSE has Zypper, Yast2 and so many other advantages over other distributions but stated to lack the stability it has had before the switch to KDE4 was done and the good old KDE3.5 was abandoned.
    Now that KDE4 finally becomes useable again, I still encounter more problems with openSUSE than with other KDE4 based distros. And that is what I found disappointing because I used to love openSUSE for it’s philosophy and wide range of great tools and are testing every new release with the sad conclusion that it is still better to stay with Debian, until times get better again.

    Best wishes!

  20. Dmitri

    “I’d like to see an openSUSE that fits in the gap between Debian and Ubuntu. Rock solid and more stable than Ubuntu, but nevertheless more up-to-date than Debian.”

    That’s it. That’s the way! I fully support this proposal.

    It’s a well-known fact that Ubuntu is not very stable and, how can I put correctly, very distinctive distro. On the other hand, Debian isn’t really intended for the desktop use. Fedora, another popular distro, is too much bleeding-edge for users who are not linux enthusiast.

    Thereby all of the above distros do not fully satisfy the requirements of users who
    a) want a stable, reliable instrument
    b) which works well out of the box
    c) do not want to mess around with software configuration
    d) or spend their time on trivial and routine stuff

    I hope 12.2 will be able to fill this gap and the old slogan will become a reality again: openSUSE – the linux for professionals.

  21. Mikes

    All my opensuse installs are text only servers so stability is the key for me.

    1 year release cycle sounds about right.
    I would like to see a longer support period aswell prehaps 3 years.

    Thanks to all the team

  22. EMil Wentzel

    I thank the openSUSE team and community for all their hardwork and for being open enough to let us, the community and users apply ourselves with suggestions to resolve and create a better future.

    Lengthening the time between numbered releases is a great way for us to become better implementers. As with many others; though I like the new stuff as often as possible, when it comes to production, I want rock stable and less need to upgrade often. I use openSUSE for everything, so it’s important to have a balance between experimenting and having something deployable.

    Tumbleweed has proven a good way of staying up-to-date with the newest and still be stable, and I think this should be a good place to but stable on the edge stuff. But OBS is best for those who want to do bleeding edge testing and development. By then taking Tumbleweed (as others here suggest) and making a numbered release with the rock steady updates in a floating release, we have the best of both directions. Most importantly, that floating release shouldn’t be within the same year as the previous release and have a LTS support on specific releases. (A random idea though, use Tumbleweed as the normal update, and a different repo {like Evergreen} for the LTS)

    I over all agree with most of what others have said here, our focus needs to be on stability and maximising off-the-install usability; not bleeding edge development (which is still important so we have a distro that is relevant).

    I look forward to continuing our work as a community :D

    Have fun!

  23. Ozzy

    I use SuSE from it’s very eraly years. I am agree that 2 cycles of distro lounch for 1 year is to fast. In my very own opinion 1 cycle for every year is enough, and improvments will be noticed. Its important to have a stable and very well supported system.
    Many many thanks for the great job that you all are doing. Wish you the best !

  24. I’m not too surprised at the problems. SUSE is like a company growing too fast. The company stumbles, redesigns its structure and functions to better serve its goals, and continues.

    What I see is mainly due to the size and complexity of the huge code base. The kind of fix I would suggest is better structure, as having a flow chart of how the whole process works so we can see what needs to be done. The lack of such a chart is part of the problem.

    The second part of the problem is complexity, complicated by code that may be old, recent, current, advanced or experimental. It is simply a bad idea to mix too many levels of code and expect stability. It ain’t gonna happen!

    What to do: Overall, more internal structure so that code in different stages of development is *not* arbitrailly mixed. Code functions (groups of code elements) should not be mixed beyond one level up or down because the chance of problems grows explosively. Obviously there will be exceptions to this rule, but only when essential.

    The overall problem is complexity. The answer is better structure and a limit to the number of stages mixed. If you have ABCDEF stages, ab, bc, cd, de, and ef are the best to pair, and development starts with A – experimental, and ends up with F – mature and in production.

    Detailing this out will take time, the rules will pain some people, but the results will be more predictable and actually scheduling a release will again be possible.

  25. juvi

    I think, that the main problem is, that developers are (sometimes) very
    isolated from users. I think, that it is reality and release concept must
    accept it and we must analyse consequence and integrate results into release
    concept.

    I agreed with prolongation development from 6 to 8 months, but I do not agree
    with prolongation to 12 months. I think, that prolongation will not bring more
    stability (it is human nature, that “I have a time…”), but it will bring
    loss a developers. More stability can bring only “edge users”, what wants “the
    top features”, what are willing to install and run quite unstable software,
    because it is their world.

    I think, that the best solution is more complicated release concept with two
    production line: developed and tuned. In this case the life cycle includes the
    whole major version (13, 14 etc.) and consist from:
    1) Developing period (12 months) what result in release “zero” distribution
    (13.0, 14.0 etc.).
    2) tunning perion (12 months) what result every 3 monts in release “one”,
    “two” and maybe “three” (13.1, 13.2 (and 13.3)) version. During this perion is
    acceptable upgrade applications (include newest DE, kernel etc.), but is not
    acceptable changing concept (systemd, compiler, new DE etc.). These version
    are only “remastering” of preceding version with updates and actualised
    packages.
    3) the main distribution period (12 months) – bugfixes
    4) supported perion (12 months) – only security bugfixes

    This propsal results in reduced the number of supported version, prolongation
    life time and “no problem zero version” (as zero version can be declared only
    for “stuntmen”. During development period will be reduced activity in tuning
    period the previous major version, so developers can one by one move to the
    new project.

    Here is place for discussion on suggested periods, maybe prolongating period
    between the major version to 18 or 24 months … but I think, that it would be
    much better satisfy to the “world of users”, than actuall concept.

  26. I think the combined concept outlined by Jos has merit. I’d certainly be happy with a working approach along those lines.

    But if part of the problem is to do with complexity and the quality of contributions then maybe there is something more that could be done to bring the standard of contribution up. Could the community publish a “code of best practise” for contributors backed by a series of tutorials aimed at guiding first time or naive contributors to a better place?

    Maybe a contributor is pointed at a check list/flow chart which says “done all these things? Good, proceed to X. No? Proceed to Y or Z.” Y and Z might be places where a contributor can get expert and rapid feedback on why their contribution is not yet fit for X.

    I could imagine myself using a very stable once a year update for my production machine but experimenting with new versions of KDE/Qt etc on virtual machines in the meantime. And the best practise stuff might help me with the experimental stuff to the point that I’d consider contributing/helping with testing etc.

  27. I used to use Ubuntu until it became too much of a Mac OS X ripoff (“software centre”, “next time we’ll be even posher”, and of course that “holier than thou” vibe).

    What I did like, however, in Ubuntu was their idea of a distro’s life cycle:
    Stable –> Pseudo-geek seducting/testing edition –> Stable.

    The things that made me switch to openSUSE (other than an unexplainable fear/disgust the one day or another Ubuntu Linux would be *just* Ubuntu without Linux) were the better — in my opinion — hardware support, the possibility to chose what NOT TO INSTALL (I don’t want Mono, stop suggesting I should get Mono).

    Now, it is obvious that something’s a little off since the few last releases (every time someone I know updates with Apper I have to fix his PC) whilst some of the new “cool stuff” is, well, cool.

    So, what to do?

    I suppose the majority has the right idea on having a 1-1.5 (even 2) year(s) really stable release plus Tumbleweed if you want to take some risks.
    I do not think this could be dangerous in a Debian kind of way (last time they had a stable I didn’t have to shave at all).

    My suggestion:

    STABLE (A) –> every 1-1.5 years (pick one, depending on how much the dev can handle)
    COOL/EXPERIMENTAL (A.b) –> snapshot of Tumbleweed (Ubuntu-style: publish an RC as stable-dot-something, but do not support it that much)
    STABLE (B)

  28. plainalt

    Hi!

    I would also vote for a release-cycle of one year, while every release is maintained and supported at least three years.

    The impatient may use Tumbleweed to get the newest stuff, but users (like me) who depend on a really stable and cleanly debugged base system, should be provided with such.

    Best wishes,
    andy

  29. Ben

    So many opinions that are unhelpful. The fact is that opensuse must be both current and stable, or people simply will not use it. It must be better in every way compared to other distrobutions, and other operating systems. Obviously this means workload reduction and reorganization.

  30. Todd

    General Eric Shinseki is quoted as saying, “If you dislike change, you’re going to dislike irrelevance even more!”

    As a long-time SuSE/OpenSUSE user I really like Coolo’s approach of delaying for some serious discussion as it embodies the founding principles of “community” that launched openSUSE to begin with!

    My vote is for the one-year release cycle and three-year support concept with a targeted focus on the quality and stability of a given release.

    A few other thoughts:

    1) The ideas of codifying the “aim” of the distro along with the flow-charts (previously mentioned) are all excellent ideas that can only unify our community.

    (2) Organizing the community, holding virtual-town-hall meetings, and even some voting-style-input as to what next year’s release will hold. I think it would be nice touch.

    (3) Develope a robust, online development tutorial that ties in and truly leverages the collaboration piece (I personally vote for “openSUSE University”) and teaches the skills necessary to become a Grandmaster of openSUSE development!

    Best Regards,
    Todd

  31. gumb

    openSUSE should consolidate more clearly around three fundamental usage types:
    1) Factory / Development
    2) Tumbleweed
    3) Stable / Evergreen

    I know this is essentially what exists already but there needs to be much stronger focus and a less scrappy ecosystem of repos and organization, e.g. for those who want the latest KDE on an otherwise Stable release. These above three types should satisfy most use cases if there is a subtle shift in engineering and users’ expectations.

    Type 1, the smallest of the user groups, is nonetheless critical and would constitute most developers, testers and others who dare to live on the bleeding edge. I imagine the existing typical user base of openSUSE will then be split fairly evenly between the other two camps.

    Those who like to keep up with latest apps, desktop environments, perhaps even kernels, would fall under Type 2, which itself would straddle the gulf between the existing regular stable openSUSE user and the Tumbleweed gang. They would be prepared to download plentiful online updates but in contrast to the current Tumbleweed it would be just a little more conservative. No giant jumps in packages or functionality, only generally well tested upgrades. So for example GNOME users might see an update from 3.4 to 3.6 but it would only arrive after a delay to allow full testing and integration. Those who must have it straight away would not suit this model and would be encouraged to join the Type 1 ‘stuntmasters’ (I saw this word before and it made me laugh).

    And for all the rest, the conservative types, servers, existing Evergreen users, Type 3 would be purely security and bug fixes.

    It’s interesting how only some months ago during the discussions about release cycles and numbering, the majority very much preferred the compromise of an 8-9 month cycle, and now clearly there is a swing to a longer one-year period. If one assumes that resources will not be increased, it would be fair to transition the existing ‘2 releases plus 2 months’ support scheme so that it covers 2 annual releases plus 2 months, i.e. 26 months. That would satisfy a percentage of long-term support and server users, and might negate the need for separate Evergreen efforts. Those who really want longer than that might just need persuading that SLE is more suited to their needs. Then again, the general savings on resources made by clearer consolidation around these three models might offer the opportunity to increase the support cycle for Type 3 users to 36 months.

    One other key factor in reducing costs for longer term support is whether each release can be based on an LTS kernel. That would need to be carefully planned in advance and discussed with kernel developers, since at present only a few kernel releases have rather arbitrarily been picked as candidates for this.

  32. For me as a user stability is important both on my desktop system, notebook and server systems. I am willing to wait for stability.

    I would rather have a much slower release schedule, and a longer period with security patches and updates. This also go for the commercial derivative products, such as SUSE. For SUSE you can buy 5 years support. If you buy a Windows product I believe security patches are included for 10 years. We are behind the competition.

    With the online upgrade function introduced with openSUSE 11.4 upgrade is not as big an issue as it used to be. However, it could be more user friendly, i.e. a command to automatically go from one set of repositories to a new one, and then upgrade, something like zypper upgrade openSUSE 11.3 to 11.4. Of course with error messages and abort if a repository is not available under the new release. Maybe even an upgrade script editor, just like the install editor the people behind eComStation (formerly OS/2) use.

  33. Ben

    Decision made :-p

    http://www.phoronix.com/scan.php?page=news_item&px=MTEyNzI

  34. Impeesa

    Linux must be free, stable and fast, we shouldn’t lose those principles. However I find the desktop version of the main distributions a bit unstable. When I’m going to install a new release, I always cross my fingers and I wonder what program will not work. Sound is a common headache.

    So in my opinion openSUSE should concentrate on a rock solid release once a year at the latest and support it for two years. For users who wish to use bleeding-edge software Tumbleweed will be the right choice, with this will approach all users win.

    Best wishes!

  35. Soren Tarp

    In my opinion I would prefer less but more stable releases, that do not need tweaking after an upgrade. I have been happily using Opensuse since 10.1 on several computers, but I have been using plenty of time to learn its functions and to tweak after upgrades, both for my self and friends. So for me the projects main focus should be on user friendliness, explainable functions and tweaks – and – in the future (I hope) a more cooperative Linux community with fewer – but more distinct distributions.

    Keep up the good work!

  36. Moz

    Even the “stable” repos in 12.1 have lots of broken packages. It is not a factory-only issue.

    The problem is that releases are simultaneously too short and the packages too freaking old.

    When 12.1 released, many of the packages were 12+ month behind the current stable versions.

    Releasing 12.2 before it is ready will damage opensuse more then delaying it ever will.

    It is sad to say but it looks like Fedora will soon be the only viable distro. The only problem with Fedora is that its admin tools suck, and admin tools are the only positive for opensuse.

  37. Jarl E. Gjessing

    I agree on 1 year release.
    Stability is one of key issues in general.

    I dont care if the packages are 1 year old as long as they are stable.
    And if I do need bleeding edge I just use Tumbleweed.

    What I really need is a stable and long supported Linux.

  38. flymail

    I think it’s difficult to comment properly without knowing all the gory details of why 12.2 is so anomalous compared to previous releases that have not suffered similar set-backs. Server administrators who demand stability probably should really be using SUSE Enterprise leaving openSUSE for the Linux enthusiasts. A fixed development cycle arbitrarily fixed to eight months is probably not helpful, however, especially when openSUSE tries to appeal to every kind of Linux user by being (IMO) the most flexible distro (my only real gripe is the default lack of GRUB2).

    For those who use openSUSE seriously however, it would be useful to have some idea of the time-frame associated with the development cycle. I think most of the suggestions made above are very sensible but obviously cannot be incorporated at once. Perhaps a flexible compromise in the spirit of the universal appeal of openSUSE would be best along the lines of:

    A new stable version of openSUSE will be released every 6-12 months depending on when it’s ready.

    I think anything too much over a year may discourage enthusiasts in this fast-moving world.

  39. Theeuwes de Jong

    IMHO its a matter of finding balance between the greatest commonality amongst users and the appreciation every human likes to receive for his or her effords.

    I have the feeling that the greatest commonality amongst users is an install once, run till obsolete attitude. If I install a SLED i expect not to revisit the machine until it leaves the company, likewise with open SuSE installs on private machines, install support till new one is bought (or change of owner occurs). Having started with Suse 6.X in the last millenium, i finaly see some acceptance on the street develop. What i see is basically that support (repos availability) ideally lasts the machines lifetime (change of ownership/user/employee). From that next Versions release date is irrelevant, as long as support for the old version is extended likewise.. A bleeding edge user/developer will like the newest greatest but if that cost the appreciaton for his/her effords from common users its a no win situation. Emphasis should be on stability and functionality = release when ready and support till demand drops (aka when all user move to new release aka nr of downloads from update repos drops to to certain % point ( eg. 10% of peek) This will asure 2 things 1. Suse user can trust they’ll have a rock solid, stable OS as long as they use it.. when it gets old they’ll understand that support drops (outdated) 2. OEM’s will see sales fluctuate with release and respective outdating of versions.. release cycles and a release’s EOL is then user orientated witch normally results happy users and their appreciation for developers accordingly. Alternatively if enthusiasts are the greatest determinator (or we want it to be) then release cycles, eol do not matter and i could add neither does stabillity. Than installs would be limited to my personal machines and machines that are only touched by me. (forget about Steam on openSuse?)

  40. Andrey Lisin

    openSUSE has three major competitive advantages, which are zypper, OBS and Yast.

    It’s very hard to explain for me, why community supports so few packages in OBS, and you know what I’m talking about. There is no successful open source project in the world without a strong community.

    Then, I believe all power users are delighted with zypper. Have you ever seen more powerful packages manager? Me definitly not. Begginers, in turn, will like Yast.

    I feel, the formula is pretty easy: strong and large community – bright future. To attract more people we need to promote the strong features of openSUSE. Making OBS the platform of choice for large projects we’ll also attract peoples. May be it’s not in open source spirit, but promotion is what we need in my opinion.

    openSUSE is a large project. It’s not only a box with open source software. There are a lot of external projects, that is needed to be supported. And here we also need a help of community.

    And even more openSUSE is still what some people mean, when saying ‘Linux’. It gives me optimism and allows to look confidently to the future.

  41. Richard

    Surely if it’s ultra stable and supported you want then you need to fork out for a paid solution. Solaris, HPUX, AIX, RedHat, SLES, SLED come to mind.

    By it’s nature a consumer product is going to need to be more cutting edge as there is more demand to run new software on newer kit with ever differing components.

  42. toes

    As far as release cycle, I feel that it’s best to be flexible with release cycle timing.

    Look at the current need for features, then determine what timing could realistically
    support a reasonable percentage of those features/changes.

    As a long time user of SUSE and then openSUSE, I have been rather surprised at some of
    the issues that have arisen in openSUSE over the last couple years or so. Some have seemed rather fundamental to have slipped into a release. I would ask to what extent, if any,
    so called TDD ( Test Driven Development ) is used in validating a release? If I’m
    thinking correctly, there have been recent times when some dependent packages weren’t
    included. That would seem something that would have been caught by automated
    testing.

    If I’m coding in Java, defining an interface, writing an automated test with something
    like JUnit to verify that the new code still conforms to the interface in the same way,
    tends to assure that things haven’t been overlooked.

    Don’t get me wrong, I realize that with diverse development languages, and diverse
    Human languages within the Community, it’s not the easiest thing in the World; we’re
    all Human, we all make mistakes.

    But when I see something like whether or not the menu choices from the grub menu.lst file are available on the reboot option when leaving a KDE session, flip-flop from point-release to point-release, as in, it’s one way on openSUSE 11.3, it’s the other way on 11.4, then it’s back the previous way on 12.1, I have to think, either there’s disagreement about how it should be, or it should be viewed as a defined interface, and that’s something that automated testing could check for compliance with the interface. Likewise for missing
    dependent packages.

    Whereas I realize that something like the auto-hiding of a KDE panel coming and going
    on the fly during operation, even though no settings have been changed, or grouping
    when minimized, changing during operation, even though no settings have been changed,
    is more nuanced, harder to detect on an automated basis, and much harder to reproduce.

    This all reminds me that it would be nice to be able to see a somewhat detailed overview of what has changed from one release to another, as well as what has been changed for openSUSE,
    relative to the way code behaved in the original packages, prior to changes specific to openSUSE. Something notably more detailed than the Release Notes typically are, but without having to try to plow through masses of code or documentation, to determine the list of changes. Essentially a feature level list would seem appropriate. If documentation were done in a structured fashion during development, it might even be possible to pull most of that from the documentation, if the dev. docs. included references to allow being automagically tied back to openFATE. Likewise, greater visibility on policies used to construct openSUSE, would make bug reporting a good deal easier. That would give much greater ability for users to decide, “Is it just a change I don’t like, or just something that I would have coded differently, if I had done it? Or is it an actual design-flaw/bug?”. I have no desire to waste people’s time reporting something that isn’t an actual problem.

  43. Sergio Mancini

    I think for openSUSE a 1 year distro release cycle with 2 year support – Evergreen version (We cannot have much time support – This is for SLES)
    is the right choice where we will have time for make things right, with a stable base with new technologies
    (new SDKs, filesystem versions, kernels, DEs and this kind of thing). This version will use Firefox and thunderbird ESR, with
    security/bug fixes only for the base and software.. a test bed for SLES.

    For those wanting more bleeding edge, we will have Tumbleweed, with the normal Firefox/Thunderbird versions
    and new kernel/software/DEs/Drivers versions, after a good test period.
    THE MAIN POINT here for me need to be this one: Tumbleweed need support only the CURRENT version, so after a new release,
    Tumbleweed will only be supported for 3 months for the early one, giving time
    for the users plan a dist-upgrade. If you wanna bleeding edge, for sure you will upgrade for a new distro release…
    so no need to continue supporting Tumbleweed in “old” stable versions;

    With this approach, we will have 2 brands, satisfing both audiences and will reduce workload for developers.

    Another thing that I think is very important is have a GREAT online Wiki, with plentfull of informations about every topic of the distro,
    alongside with How-Tos for new users;

    One appeling point in this case will be have a new screen in the installer, where the user input what “Version” of the distro he want:
    If Evergreen, install the base Distrowith the stable branch/repositories and if choose Tumbleweed, already configure the repositories accordingly.

  44. I have to add one thing on the annual/other major upgrades.

    I think that *forcing* a one year pace when a lot of new function is arriving is a receipe for repeated disasters. We need to be more flexible.

    A new release with major upgrades should be allowed 15 to 18 months for proper integration and testing. This would be appropriate for 12.2, or any similar big jump so we don’t expect miracles. And miracles is what it would have taken.

    Each upgrade should be evaluated as to complexity when being designed and scheduled, with possible extensions if we find serious problems along the way.

    Part of the problem is wanting all the new stuff ASAP, and part of it is impatience. We need to move with more care. I recommend 9 to 12 months for typical intermediate upgrades, and 15 to 18 months for major changes.

    I want to also suggest that 2 year lifetimes are awkward for some of us, who prefer not having new function too frequently. I’m not primarily a systems person any more, but more a cross between that and a high end user. I’d like 3 year life for alternate versions so as to give users like me more time to swing into the new stuff, maybe in parallel with the old one.

    And one more suggestion: It would be nice to have some new systems come out with optional virtual operation so anyone could hold the old and experiment with the new simultaneously.

    Best wishes from BillN

  45. Tarik

    Delayed releases are a fine solution to stability – take some time to formalize priorities and get the most important tools perfect. Remember to maintain flexibility, though. Keep us all informed, but don’t get locked into a mindset about schedules short *or* long.

    I’ve been using openSUSE since 10.1 and I remember upgrading to 11.0 on release day. It was a rough transition, to say the least. I’ve used a lot of distros, though, and I still think openSUSE is the best one.

    Learning how to use yast and get stable binaries is really important for new users joining the community. The newest stable release is the piece that everyone will see as our cutting edge and it should not be blunted by lack of polish or app crashing. It would be ideal if the included software on the release CD/DVD was so stable it only needed security updates after install, and all other apps/tools were left to OBS or source compilations.

    Another commenter mentioned “OpenSUSE University” to teach people more about how to install/use/build packages and I think this is a great idea. Some troubleshooting and configuration pages are out-of-date or point to empty pages now, and what would really help is a mentoring system where experts pass on their knowledge and usage habits to new users.

  46. Bruce

    Longer release cycles are not fine, but should be used at this point (i.e. 12.2 must be delayed).

    In general, a combination of approaches work best, followed by polishing as needed. These proposed changes are, after all, polishing of the current scheme.

    Anyway, a one year cycle is too long. I’m waiting for a KDE refresh because the 12.1 one was too unstable and I’ve learned I don’t like Gnome at all. I could learn how to install an out-of-SuSE-repo KDE, but I don’t want to. The Linux desktop is difficult enough without going out of my way to use untested combinations. So I am waiting (a little bit impatiently) for 12.2.

    WRT staging changes, I think the Debian scheme of requiring a package to live in the unstable branch for a while before integration is completely reasonable. WRT critical build infrastructure (e.g. the version of GCC used to build the entire platform), you might reasonably add a few hoops and more soak time. There is also no reason you could not put out a 12.2 built with GCC 4.6 but shipping with 4.6 and 4.7, except you have likely gone through most of the 4.7 pain by now.

    So I anxiously await 12.2. Thank you.

  47. Niclas

    I use OpenSuSE for my webmail server / firewall / samba share, so I would very much want a longer release lifetime. 3 years is a minimum. I am currently trying out the Ubuntu 5-year release, but I like SuSE a lot better, so I am having a difficulty deciding.

    Nevertheless, I can’t re-install my server every < 18 months. Its' simply not long enough for a server. Whatever my choice turns out to be, it will probably remain my choice for several years to come. Had SuSE adopted a lifetime system similar to Ubuntu, the choice would be very simple for me.

    I have been a very happy user since release 7.3. Thanks for your hard and very good work so far.

  48. abdelrebel

    I prefer a long term support releases. I hate having to upgrade or reformat and do a fresh install every now and then. It involves a lot of unwanted hassle for many users including myself.
    Many thanks to opensuse team.