OpenSUSE Team Reworking Dev Model, Delays 12.2 Release 38
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."
Re: (Score:2)
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".
Re: (Score:1)
Re: (Score:2)
Well, I have to disagree with you. I've just done an LVM with Luks install of F16 on a T500. No issues whatsoever.
Re: (Score:1)
It's harder than it looks (Score:5, 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. :)
Re:It's harder than it looks (Score:4, 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.
Re: (Score:2)
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)
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
Re: (Score:2)
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)
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
I hasn't got worse (Score:4, 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.
Re: (Score:3)
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 packe
Re: (Score:2)
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.
Re: (Score:2)
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!"?
Don't bite off more than you can chew (Score:2)
Seems like a smart move (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 [boingboing.net]
Re: (Score:1)
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.
Re: (Score:3)
...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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (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
Re: (Score:3)
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
Improvements (Score:2)
Re: (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 w
Re: (Score:1)
Re: (Score:2)
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.