Slashdot Mirror

← Back to Stories (view on slashdot.org)

OpenSUSE Team Reworking Dev Model, Delays 12.2 Release

Posted by timothy on from the when-big-turns-make-sense dept.

LinuxScribe writes "The upcoming 12.2 RC1 release of openSUSE has been delayed, and the final 12.2 release 'won't see the light of day on July 11th,' as developers within the openSUSE community struggles to fix their release efforts, Community Manager Jos Poortvliet said today." Says the article: "Among [openSUSE Release Manager Stephan] Kulow's suggestions? Dumping the current release cycle schedule for openSUSE and moving to an annual or even unscheduled release system."

38 comments

  1. Distros :: an annual or even unscheduled release.. by Anonymous Coward · · Score: 0

    Best idea. Fedora has really gone to pot since 12 and especially after 14.
    Set up a LVM with Luks, install and works great up to 14. After that, it won't
    boot (but allowed the install to complete). vim's broke, gnome terminal won't
    hold it's size, and a myriad of other issues that didn't appear in prior releases.

    I'm considering the move to SuSE, but I hope their schedule allows for working
    releases rather than a hard date - just ship it mentaility.

    CAPTCHA = ingrate (really?)

  2. It's harder than it looks by laffer1 · · Score: 4, Insightful

    I wish the OpenSUSE project luck getting this figured out.

    Maintaining packages in this manner is a lot of work. At the end of the day, most contributors only work on a handful of packages and don't consider the possible breakage of other packages. One or two people end up doing all the cleanup work. This happens in the BSD community all the time. For instance, if you look at the recent issues in FreeBSD when PNG was updated or the new debate about X.org 7.7 coming into the tree. FreeBSD's approach to ports is great when you want up-to-date software, but the maturity found in NetBSD's pkg-src or even OpenBSD's model sounds a bit more like what OpenSUSE is looking for.

    I'm not trying to pick on FreeBSD. I use a similar process for MidnightBSD due to limited developer resources. In my case, it usually means I personally have to update packages. That's why we have such outdated versions of Firefox (unbranded of course) and Chrome. Not only do all the other dependancies have to be the right magic versions, but someone has to take the effort to port a rather complex piece of software. Luckily, the Linux folks don't have nearly the trouble as they're a tier 1 platform for most software these days. Still, there are many different choices in linux for near everything and getting your combination to work can be tiresome. Next time you download packages from any open source OS, consider how much work went into that easy experience. Saying thank you can't hurt either. :)

    --
    MidnightBSD: The BSD for Everyone
    1. Re:It's harder than it looks by ThePhilips · · Score: 3, Informative

      Linux folks don't have nearly the trouble as they're a tier 1 platform for most software these days.

      On the positive side, if you know Linux, you have better chances of finding why the piece of software refuses to compile/link.

      I'm no distro maintainer, but I do a share of platform porting. In my experience it is actually reliance on GCC (and prehistoric crap inside /usr/include/) which is more of a problem. Only after experiencing all that fun trying to compile open source software using non-GCC compilers (aCC, SunStudio, xlc), I have fully realized what kind of hurdle CLang developers and users have ahead of them.

      --
      All hope abandon ye who enter here.
    2. Re:It's harder than it looks by Anonymous Coward · · Score: 0

      A lot of things broke in Linux distros as well related to that libpng update.

    3. Re:It's harder than it looks by buchner.johannes · · Score: 1

      Maintaining packages in this manner is a lot of work. At the end of the day, most contributors only work on a handful of packages and don't consider the possible breakage of other packages. One or two people end up doing all the cleanup work. This happens in the BSD community all the time. For instance, if you look at the recent issues in FreeBSD when PNG was updated or the new debate about X.org 7.7 coming into the tree. FreeBSD's approach to ports is great when you want up-to-date software, but the maturity found in NetBSD's pkg-src or even OpenBSD's model sounds a bit more like what OpenSUSE is looking for.

      The sad thing is that this boring job is done for every distribution separately. Imagine how much developer time would be saved if someone could figure out how to make (tested) packaging work across distributions.

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    4. Re:It's harder than it looks by Anonymous Coward · · Score: 1

      There are some pieces that help with that...

      The OpenSuSE Build Service (builds for other distros as well)
      https://build.opensuse.org

      Some tools available for packaging/testing..
      http://en.opensuse.org/openSUSE:Build_Service_Tools

    5. Re:It's harder than it looks by timbo234 · · Score: 1

      I'm not knocking the OBS, it's a very useful tool, but it really doesn't help much here since making a package that works cross-distribution would involve a lot of manual integration work.

      For example I could easily use the OBS to take my Opensuse package for foo and build it on Fedora and ensure it at least builds and is installable. However the real work, integrating it into the Fedora distro and ensuring it works well with and is the right version for the other packages in that distro, is not done by the OBS and isn't easily automated.

      If you look in the mailing list thread on this article you'll see it's exactly that kind of integration work and the difficulties with it (even within one distro) that's causing the problems. Probably the most realistic model is the Debian one where several distros (Mint, Ubuntu etc.) feed off and (hopefully) contribute back to a central packaging effort. IMHO the number of packages in a modern Linux distro is getting too much, and the integration work too complex, for smaller projects like Opensuse.

      --
      Pre-canned Evolution Links for all those Slashdot holy wars.
    6. Re:It's harder than it looks by icebike · · Score: 2

      Not only do all the other dependancies have to be the right magic versions, but someone has to take the effort to port a rather complex piece of software. Luckily, the Linux folks don't have nearly the trouble as they're a tier 1 platform for most software these days. Still, there are many different choices in linux for near everything and getting your combination to work can be tiresome. Next time you download packages from any open source OS, consider how much work went into that easy experience. Saying thank you can't hurt either. :)

      Too many moving targets. Too many artificial dependencies.

      I've often found that dependencies are carelessly chosen, then enshrined into the RPMs, when in fact there is no real dependency on having the absolute latest version of some lib or some other package. The package builder or the developer happened to have version 1.35.34-1a installed even thought they USED nothing from that lib or package that was new or fixed since 1.26.0.

      Consequently it becomes a mad dash for every maintainer to gather a snapshot in time of stable system from a zillion packages all being updated asynchronously.

      OpenSUSE releases have a lifetime of 2 releases + 2 months overlap. With a release cycle of 8 months this makes it 18 months before any given release falls into obsolescence, becomes unmaintained. See http://en.opensuse.org/Lifetime

      Add to this that OpenSuse was simply a test bed for Novell's commercial packages (SLES/SLED) and you have the perfect storm of rapid rolling obsolescence. Releases seem to become obsolete and unmaintained way too quickly.

      I would enjoy annual releases. I would enjoy releases every two years even more. I could make a case for a release every three years with nothing but security patches and major fixes bug between.

      But most of all I would love to see a release maintained for 3 to 5 years.

      I love this distro, ad have been running it since version 5 or 7 or some such. But Running OpenSuse has become an exercise in chasing new releases every 18 months just to avoid obsolescence and security problems. 18 months is just too short.

      --
      Sig Battery depleted. Reverting to safe mode.
  3. SuSE by Anonymous Coward · · Score: 0

    Found my old boxed copy of SuSE 8.1 recently. Linux was actually good back then. Almost 10 years have past and Linux has gotten worse on the desktop.

    1. Re:SuSE by rbrausse · · Score: 1

      Almost 10 years have past and Linux has gotten worse on the desktop.

      nah, this is too harsh.

      I don't like Gnome 3 (and switched to LXDE) and hate PulseAudio with all passion, but comparing Fedora Core 3 with Fedora 16 (exactly 7 years of development) I see an amazing improvement.

    2. Re:SuSE by WrongSizeGlass · · Score: 1

      Found my old boxed copy of SuSE 8.1 recently. Linux was actually good back then. Almost 10 years have past and Linux has gotten worse on the desktop.

      Isn't that right about the time someone declared "This is the year of Linux on the desktop!"?

  4. Re:Fiber is so important by azalin · · Score: 1

    The most important part of your day is fiber, which helps keep the cycle regular.

    I imagine an annual release cycle in this context to be rather "unpleasant".

  5. Don't bite off more than you can chew by thereitis · · Score: 1

    No matter what the release frequency, you need to carefully choose what goes into a release, and it doesn't sound like that's happening here. It doesn't matter what your release timeline is - you can still run over the deadline if you don't plan carefully or if you allow scope creep. I don't think lengthening the release timeline in SuSE's case would necessarily help anything. In fact, shortening it would likely be more effective. Each time you do a small release, you can refine your estimation skills and get better at choosing what goes into a release. On a long-lived project, this is probably harder. I'd also caution against an unspecified release date - SuSE needs to stay fresh and relevant. Waiting 2 or 3 years for an upgrade will not cut it for a lot of users.

  6. I hasn't got worse by Viol8 · · Score: 3, Insightful

    Its a lot easier to use - 10 years ago if for example you double clicked on an AV link you'd just be met with a "Huh?" prompt from the window manager and would have to go find an app that could read it. Similarly most MS Office file formats were a game of chance with the free software around at the time.

    Having said that , there does seem to be a tendancy for distro devs to pack in the the latest stuff into a release simply because its available , rather than going for stablity and interoperability with maybe slightly older versions of software.

    1. Re:I hasn't got worse by c0d3g33k · · Score: 2

      Having said that , there does seem to be a tendancy for distro devs to pack in the the latest stuff into a release simply because its available , rather than going for stablity and interoperability with maybe slightly older versions of software.

      To be fair to them, end users tend to clamor for the latest stuff and tend to consider the presence of older versions a net negative when discussing a distro. On the other hand, a developer is more likely to prefer the cutting edge by nature, and often has a tweaked system that works for them, so tend not to notice that the latest stuff doesn't work properly on a stock version.

      There's also the problem that for some applications or tools, the latest stuff is actually better and preferable so should be packed into the distro, particularly for stand-alone apps that don't integrate deeply with other components of the system or desktop. It's the latter that one has to be careful with, but devs don't always seem to make the distinction cleanly.

      And don't get me started about upstream developers that insist on using the latest beta or alpha versions of libraries or toolkits rather than the stable releases that are actually shipped with recent distro releases. Trying to shoehorn in a newer version of an application that has a crucial bug or security fix but depends on an unstable version of a library is an exercise in pain.

  7. Seems like a smart move by c0d3g33k · · Score: 5, Interesting

    I was a happy OpenSUSE user for several years, but abandoned it after the 12.1 release. My reasons were quality and stability issues that had been on the rise over the last few releases, which culminated in the premature (IMHO) and half-assed transition to systemd in 12.1. That was the last straw and the trigger to embark on another distro-walkabout (I won't say what I ended up switching to, because this isn't about that).

    There is a lot to like about OpenSUSE and it's probably still one of the best distributions to use for a nicely integrated and well supported out-of-the-box KDE environment. But the incidence of instability (generally user-facing stuff - the base environment of kernel, toolchain and libs is pretty rock-solid), random bugginess (usually caused by a lone developer or small team marching to their own drummer without regard to their surroundings) and poor integration of interacting components has been creeping up over the last few years. It seems that people in the OpenSUSE development team have taken notice and started to think about the causes and how to address them. Bravo to them for having the insight to notice and the balls to try and address the problem before pushing out a release.

    Not that they probably care too much about what I think*, but I'll be watching carefully and may give the next release another chance.

    ---
    * The developer community is probably one of the more unconsciously user-hostile developer groups I've encountered in awhile. A fine and dedicated bunch, but they tend to keep to themselves in places apart (mailing lists, IRC) from where the users hang out (forums.opensuse.org). A typical response when a user is baffled about some problem or wants to discuss improvements is the typical "well did you file a bug report" (delivered in an imperious and self-important manner by the a senior forum user or appointed moderator who are just a little too zealous in their developer worship), or the suggestion that users join the mailing lists if they want to be heard because the developers don't use the forums (don't want to be too close to the hoi polloi, after all). Meritocracies do indeed become oligarchies, apparently. http://boingboing.net/2012/06/13/meritocracies-become-oligarchi.html

    1. Re:Seems like a smart move by Anonymous Coward · · Score: 0

      yeah! That systemd change in 12.1 almost bit my friggin head off :-(

    2. Re:Seems like a smart move by red+crab · · Score: 1

      The biggest thing they have fucked up in 12.1 is the power management. I now do get around 15 mins of extra battery backup on my 4 cell Vostro laptop, compared to version 11.2, but the system refuses to gracefully shut down or hibernate most of the times. Plus, the boot up time has gone up by 1 minute.

      I still prefer them over Fedora though, which is always shipped with random anaconda bugs. Also openSUSE's software repo setup is a breeze compared to Fedora.

    3. Re:Seems like a smart move by Zontar+The+Mindless · · Score: 2

      ...the system refuses to gracefully shut down or hibernate most of the times. Plus, the boot up time has gone up by 1 minute.

      I've had almost exactly the opposite experience moving from 11.3 to 12.1. Boots a bit faster, and shutdown is about 3 times as fast.

      --
      Il n'y a pas de Planet B.
    4. Re:Seems like a smart move by Anonymous Coward · · Score: 2, Informative

      Part of the problem with Linux in general, and Suse in particular, is that when you do file a bug report the response is "work on it yourself." I filed bug report once After carefully documenting how to cause a serious problem and filing a bug report detailing the steps to reproduce it. I'm not a developer and didn't want to become one. However, I am a reasonably knowledgeable user. Out of courtesy I spent many hours tracking down the exact sequence of events which would cause the issue, corruption of a configuration file. (No, I wasn't messing with the file myself. I was using standard tools in the distribution to configure remote access through VNC.) I figured I'd done a good thing and someone would pick up the information I had submitted and fix the error. Instead I got a response asking me to track down the source code and recommend a patch. When I explained that I was not in a position to do that I was told "Well, that's the way the community works. If you don't have time to work on the problem we don't have time to help you." I was stunned.

    5. Re:Seems like a smart move by Barsteward · · Score: 2

      Did you do an update or fresh install? Every time i've tried update, i've had to go back and do a fresh install. The update process doesn;t seem to take into account config changes and delete old config keys/values.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    6. Re:Seems like a smart move by c0d3g33k · · Score: 2

      Thanks, that illustrates quite well my peripheral point in the footnote about SUSE developers being generally (and somewhat unconciously) user hostile. Treating motivated, willing and helpful participants in your distro experience as nothing more than underperforming developers who just aren't conforming to cultural norms is a symptom of the problem. I could probably sum it up as: the ultimate goal of a distribution is not to be a personal toy for developers to amuse themselves, but rather to be a tool that people use to accomplish other tasks. That's the whole point of a general purpose operating system.

    7. Re:Seems like a smart move by pnutjam · · Score: 1

      I have updated on several machines and had no problems. It was tedious and I had to zypper up and restart several times. Granted, these are headless machines, but I do run a GUI via NX.

      --
      Cheap storage VM.
    8. Re:Seems like a smart move by red+crab · · Score: 1

      I tried out with a fresh install on a separate partition first. But that was even worse, the system didn't get to hibernate at all. Finally i decided to go for an upgrade, since it didn't make any sense to run an old version for long. True, their upgrade process isn't that good, some old configs get deleted. Also, never try to upgrade with YaST, i.e while being booted in the old version, you are most likely going to end up with a broken system.

  8. Improvements by TheNinjaroach · · Score: 1

    I'm not disappointed in a slower release cycle. It should improve the quality of each release.

    --
    I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
    1. Re:Improvements by Uncle+Warthog · · Score: 3, Insightful

      I'm not disappointed in a slower release cycle. It should improve the quality of each release.

      I think so too. I've been using openSUSE since it was SuSE Linux Professional and, before that, just S.u.S.E. Linux. They had an approximately annual release schedule for the newer, pre-Novell, versions and didn't try to stuff in every single newest thing going. I like to think this gave them the time to make sure that the vast majority of what they did ship worked well.

      Unfortunately, a combination of changing to the "me-too" scheduling of releases (IIRC, the original discussion of the release schedule was calling for 6-month releases so they could be just like Fedora; after an attempt or two to maintain that, they switched to the schedule they're on now) and turning it into a beta-test for unfinished and premature software (systemd, pulseaudio, KDE 4.0, and the disaster that was online updates starting in the 10.x versions) have really degraded the distribution from what it once was.

      From what I can see this moved the emphasis from shipping a distribution with what I'd call good "fit and finish", a good selection of software almost all of which worked correctly, no nasty surprises in the base functionality of the OS, etc., to trying to ship to a schedule, ready or not and ignoring anything that didn't get them there. I know the majority of bug reports I've made in newer versions got marked "wont fix"; not "can't duplicate" or "working as designed", but "won't fix", i.e. "yes, we know about it and know that it's broken but won't do anything about it". Not a good sign for a distribution that had been previously known for its functionality and stability.

      I'm hoping that this serves as a wake-up call to the developers and that the suggestions coolo and others in the discussion are making will get them back toward shipping a distribution that's closer to what the old SuSE Linux was known for. What I'm seeing in the discussion is looking good so far.

  9. Re:Distros :: an annual or even unscheduled releas by RotateLeftByte · · Score: 1

    Well, I have to disagree with you. I've just done an LVM with Luks install of F16 on a T500. No issues whatsoever.

    --
    I'd rather be riding my '63 Triumph T120.
  10. Re:Frosty by Anonymous Coward · · Score: 0

    p1sz.

    Well you might just wind up with an OpenSuSe distro that is not full of failures & h0les best move i ever made was jumping ship i now run bang up to date with a mere fraction of the problems i had with the last few suse releases ..

    Go figure

  11. Re:Distros :: an annual or even unscheduled releas by Stachybotris · · Score: 1

    Really? I found 14 to be fairly good. I skipped 15, went to 16 and found so many problems that I'm glad 17 came out a scant 10 days after my upgrade. On 17 I haven't had any issues yet aside from some KMail-specific ones related to opening external HTML in messages causing a segfault. But as far as SuSE goes, yes, I have to agree. I have too many customers who insist on using it, won't upgrade, and so lose all ability to patch one year after release. I feel for them since they can't be easily brought up to the latest security fixes, but I don't feel for them because they won't provide an outage window to do a full reinstall & upgrade.

  12. Re:Distros :: an annual or even unscheduled releas by Anonymous Coward · · Score: 0

    http://forums.fedoraforum.org/archive/index.php/t-263586.html

    More research will show the bug number and their stupid response
    (sorry don't have time to get the link for you).

    And, yes I ran into this myself.

    CAPTCHA = whenever (really - agian? How does this know!)

  13. Suits me by Anonymous Coward · · Score: 0

    They really should ask the end-users.

    I use openSUSE with LXDE, and I'd be perfectly happy with a 12 or even 18-month release cycle if it was more robust.

    1. Re:Suits me by DECTerm · · Score: 1

      Suits me too! I recently tried fedora 17... I spend almost one afternoon to understand why the heck the xsane on the F17 could not recognize the scanner part of my multifunction laser/scanner (samsung scx-3200) , (on OpenSUSE and Kubuntu, it was a 5min task to edit a file into the /etc/sane.d/ ) then I finally re-complied the 3.4 kernel and 'played' with the /proc/bus/usb access properties. then EVERYTIME I booted the darn system I got errors from this abomination called SELinux, which finally deactivated it, then I installed the beta OpenSUSE 12.2 , runs without any problem now..(even ITS a beta)

  14. Re:Dear openSUSE/Novell: Go DIAF by c0d3g33k · · Score: 1

    Really. Over 5 years ago? That's all you've got? And OpenSUSE is a community driven OS from what I can observe, though Novell employees do contribute. You should really be ranting about SLES if you want to make this about the behavior of corporations.

  15. Re:Fiber is so important by halfkoreanamerican · · Score: 1

    That's the entire point of this... if it's only once a year it will be extremely painful. The more regular they are the more healthy you will be, both as an individual and as a software company. Companies making regular releases can respond much more quickly to user needs--that is what my company does it the customers are very happy.