Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux Business Operating Systems SuSE Linux

OpenSUSE Team Reworking Dev Model, Delays 12.2 Release 38

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

OpenSUSE Team Reworking Dev Model, Delays 12.2 Release More

OpenSUSE Team Reworking Dev Model, Delays 12.2 Release

Comments Filter:

  • It's harder than it looks (Score:5, Insightful)

    by laffer1 ( 701823 ) <luke@@@foolishgames...com> on Thursday June 14, 2012 @09:05AM (#40321483) Homepage Journal

    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. :)

    • Re:It's harder than it looks (Score:4, Informative)

      by ThePhilips ( 752041 ) on Thursday June 14, 2012 @09:18AM (#40321599) Homepage Journal

      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.

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

      • Re: (Score:1)

        by Anonymous Coward

        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

        • 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

    • Re: (Score:3)

      by icebike ( 68054 ) *

      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

  • 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 a

  • Seems like a smart move (Score:5, Interesting)

    by c0d3g33k ( 102699 ) on Thursday June 14, 2012 @10:16AM (#40322239)

    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 [boingboing.net]

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

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

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

        • Re: (Score:2)

          by pnutjam ( 523990 )
          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.
        • 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.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      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

      • 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 t

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

    • Re: (Score:3, Insightful)

      by Uncle Warthog ( 311922 )

      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 w

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close