2012/6/11 Stephan Kulow :

On 11.06.2012 11:43, Christophe Giboudeaux wrote:

...

Backtrace: http://paste.opensuse.org/view/raw/77039501 Valgrind log: http://paste.opensuse.org/view/raw/36206815

This is most likely bnc#765519 - and yes, there is so much work left to do that we should really slip (behind the vacation time) and release in september/october - and then drop 12.3 to give time to catch up.

Greetings, Stephan

The saturday I updated beta1 to factory, and the new kernel (kernel-desktop-3.4.0-3.1.x86_64.rpm) do'nt has all the dep files (only 2), and do'nt hatte network and sound. I must to create it with "depmod -aq". After that, it works fine. Regards, Juan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2012-06-11 at 11:52 +0200, Stephan Kulow wrote:

This is most likely bnc#765519 - and yes, there is so much work left to do that we should really slip (behind the vacation time) and release in september/october - and then drop 12.3 to give time to catch up.

Greetings, Stephan This also raises the question of support for N-2. With 18 months support, 11.4 EOL's in September. By default, that means N-2 gets supported for 2 months after the most current release is released.

This also raises the question of support for N-2. With 18 months support, 11.4 EOL's in September. By default, that means N-2 gets supported for 2 months after the most current version is released. N+2 = (13.1) Slated for November 2013 N+1 = (12.3) Slated for March 2013 (now possibly skipped) N = (12.2) Slated for July 2012 (now delayed) N-1 = (12.1) Supported until May 2013 N-2 = (11.4) Supported until September 2012 Perhaps we should remove the "18-month Rule" and re-define it as "N-2 gets support always until 2 months after most current version is released"? If we modified this then, assuming 12.2 releases in September: N+2 = 13.2 Slated for release July 2014 (release and support cycles back to normal) N+1 = 13.1 Slated for release November 2013 N = 12.2 Slated for release September 2012-Supported until September 2014 N-1 = 12.1 Supported until January 2014 (because 12.3 is dropped) N-2 = 11.4 Supported until November 2012 (extended because of 12.2 delay) I'm not proposing a discussion about the overall opinion of whether 18 months is adequate in general. Only in terms of how it affects the current release cycle schema. Bryen M Yunashko openSUSE Project -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jun 12, 2012 at 11:44 AM, Patrick Shanahan wrote:

* Bryen M Yunashko [06-12-12 14:36]:

...

On Mon, 2012-06-11 at 11:52 +0200, Stephan Kulow wrote:

...

Greetings, Stephan This also raises the question of support for N-2. With 18 months support, 11.4 EOL's in September.  By default, that means N-2 gets supported for 2 months after the most current release is released.

This also raises the question of support for N-2.  With 18 months support, 11.4 EOL's in September.  By default, that means N-2 gets supported for 2 months after the most current version is released.

N+2 = (13.1) Slated for November 2013 N+1 = (12.3) Slated for March 2013 (now possibly skipped) N = (12.2) Slated for July 2012 (now delayed) N-1 = (12.1) Supported until May 2013 N-2 = (11.4) Supported until September 2012

Perhaps we should remove the "18-month Rule" and re-define it as "N-2 gets support always until 2 months after most current version is released"?

I believe that is the most logical scenario.

...

If we modified this then, assuming 12.2 releases in September:

N+2 = 13.2 Slated for release July 2014 (release and support cycles back to normal) N+1 = 13.1 Slated for release November 2013 N = 12.2 Slated for release September 2012-Supported until September 2014 N-1 = 12.1 Supported until January 2014 (because 12.3 is dropped) N-2 = 11.4 Supported until November 2012 (extended because of 12.2 delay)

I'm not proposing a discussion about the overall opinion of whether 18 months is adequate in general.  Only in terms of how it affects the current release cycle schema.

While I prefer longer cycles, I believe this is acceptable. -- (paka)Patrick Shanahan       Plainfield, Indiana, USA      HOG # US1244711 http://wahoo.no-ip.org        Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org                           openSUSE Community Member Registered Linux User #207535                    @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I think this all started when a release was so late that the community decided to shift from a six-month cycle to an eight-month cycle. We moved the goalposts. Now we're on an eight-month cycle and are about to move the goalposts again. The unfortunate fact of software project management is that stuff happens. openSUSE took some hard disk crashes recently, Fedora slipped Beefy Miracle three times for show-stopper bugs, and I'm sure Ubuntu has had some recent slips as well. Now that we have Tumbleweed, we could presumably do what Debian/Mint and Gentoo do - ship a "stable" release when everything is stable, provide bug fixes and security updates against stable in "Updates" and provide new features in Tumbleweed. "Factory" would be the equivalent of Debian "testing" and OBS the equivalent of "sid". Or we could go back to six-month release cycles, tighten our discipline up to work within that and take occasional slips for show-stopper bugs like Beefy Miracle did. As a user I don't have a strong preference - I run things out of OBS and even a few developers' home repositories. My openSUSE partitions typically use over a dozen repositories. When I need stability there's Windows 7 on my laptop. ;-) But I think we do have to do one or the other - ship stable only when we have stable or bite the bullet and go back to a six-month cycle like Fedora and Ubuntu. -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jun 12, 2012 at 02:45:14PM -0500, Bryen M Yunashko wrote:

On Tue, 2012-06-12 at 12:32 -0700, M. Edward (Ed) Borasky wrote:

...

I think this all started when a release was so late that the community decided to shift from a six-month cycle to an eight-month cycle. We moved the goalposts. Now we're on an eight-month cycle and are about to move the goalposts again.

Discussion of moving goalposts may be warranted, but I'll leave that for the List to discuss it. For me, I'm only attempting to re-define the definition of support here. Because support says "18-months" it clearly puts us out of sync with any delays or changes in the release-goalpost.

By removing "18-months" and replacing it with "2 months+", we simply create a very flexible scenario that automatically reacts to actual releases. Regardless of whether we go six months, 8 months, or 50 years, support of N-2 will always be 2 months+.

I think this is the safest approach and will eliminate any support discussions similarly if future releases get delayed again.

The only potential future discussions would be if someone wanted to propose changing "2 months" to some other number of months/years. But that's an entirely different discussion that involves not only ideal support cycles, but also whether resources exist to support it.

Actually the definition we used is _2 months after the next next release_. So 11.4 will be supported by us until 2 months after 12.2 is released. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jun 12, 2012 at 12:45 PM, Bryen M Yunashko wrote:

On Tue, 2012-06-12 at 12:32 -0700, M. Edward (Ed) Borasky wrote:

...

I think this all started when a release was so late that the community decided to shift from a six-month cycle to an eight-month cycle. We moved the goalposts. Now we're on an eight-month cycle and are about to move the goalposts again.

Discussion of moving goalposts may be warranted, but I'll leave that for the List to discuss it.

Which is why I made that last post. ;-) Fedora and Ubuntu have clearly gone down the one path, Debian and Gentoo down the other. openSUSE *was* on the same path as Fedora and Ubuntu but now we appear to be evolving independently of *user* expectations, which I think is a problem.

 For me, I'm only attempting to re-define the definition of support here.  Because support says "18-months" it clearly puts us out of sync with any delays or changes in the release-goalpost.

By removing "18-months" and replacing it with "2 months+", we simply create a very flexible scenario that automatically reacts to actual releases.  Regardless of whether we go six months, 8 months, or 50 years, support of N-2 will always be 2 months+.

I think this is the safest approach and will eliminate any support discussions similarly if future releases get delayed again.

The only potential future discussions would be if someone wanted to propose changing "2 months" to some other number of months/years.  But that's an entirely different discussion that involves not only ideal support cycles, but also whether resources exist to support it.

Bryen

What do the *users* need? Fedora and Ubuntu seem to be very clear in setting users' expectations about support, making commitments and sticking with them unless there are good reasons to slip a date. Debian is very clear that "Stable" is a perfectionist distro that won't go out the door until it's dependable and supportable. Gentoo's "social contract" is similar. I say we have to do what we can to keep our commitments in the face of the slips and the disk crashes, and I'm sure the community will. 12.2 will come out some time this year and 11.4 will be supported as long as it has to be supported. But I don't think it's a matter of tweaking parameters on how long we support something ... I think it's a more fundamental decision about users' needs and how to operate to meet them. I wish I had solid data on users' needs. I suppose one could scrape the web for Fedora, Ubuntu, Debian, Gentoo and openSUSE discussions and apply natural language processing technology to figure that out. But I'm guessing the openSUSE model doesn't work, the Debian and Gentoo models work for sophisticated IT users and the Fedora / Ubuntu model works for "the masses". If *I* were making the decision, I'd say "let Ubuntu and Fedora fight it out for the mass market and switch to the Debian / Gentoo model". Because I think that's the way openSUSE is evolving anyhow - a strong, sophisticated community of IT users and technologies like Open Build Service and OpenQA. I'm using openSUSE and not Debian or Gentoo because of that. -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Jun 13, 2012 at 11:33 AM, Jos Poortvliet wrote:

On Tuesday 12 June 2012 13:41:50 M. Edward  Borasky wrote: <snip>

...

If *I* were making the decision, I'd say "let Ubuntu and Fedora fight it out for the mass market and switch to the Debian / Gentoo model". Because I think that's the way openSUSE is evolving anyhow - a strong, sophisticated community of IT users and technologies like Open Build Service and OpenQA. I'm using openSUSE and not Debian or Gentoo because of that.

I'm entirely on the same page with you.

A 1 year release schedule and using OBS and Tumbleweed to satisfy the needs for those needing more up-to-date software seems perfect to me.

Let's be honest - if you want the latest, 6, 8 or 12 months - it's all too slow so you use Tumbleweed anyway. If you want stable, 12 months is better than 8 is better than 6. Simple.

if it happens to help our release engineering, awesome too ;-)

Every November a stable release ... makes the naming a lot easier. ;-) But why not go the Gentoo route? *Every* package individually gets declared stable eventually - they don't release when the kernel, compilers and desktops all go stable. I think Tumbleweed needs to be separated into kernel and user sections. Unless I'm doing kernel-level work, I only want bug fixes / security updates in the kernel but I want the latest browsers, office tools, compilers, desktops, etc. -- Twitter: http://twitter.com/znmeb Computational Journalism Server http://j.mp/compjournoserver Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 13 June 2012 11:41:28 M. Edward Borasky wrote:

On Wed, Jun 13, 2012 at 11:33 AM, Jos Poortvliet wrote:

...

On Tuesday 12 June 2012 13:41:50 M. Edward Borasky wrote: <snip>

...

If *I* were making the decision, I'd say "let Ubuntu and Fedora fight it out for the mass market and switch to the Debian / Gentoo model". Because I think that's the way openSUSE is evolving anyhow - a strong, sophisticated community of IT users and technologies like Open Build Service and OpenQA. I'm using openSUSE and not Debian or Gentoo because of that.

I'm entirely on the same page with you.

A 1 year release schedule and using OBS and Tumbleweed to satisfy the needs for those needing more up-to-date software seems perfect to me.

Let's be honest - if you want the latest, 6, 8 or 12 months - it's all too slow so you use Tumbleweed anyway. If you want stable, 12 months is better than 8 is better than 6. Simple.

if it happens to help our release engineering, awesome too ;-)

Every November a stable release ... makes the naming a lot easier. ;-) But why not go the Gentoo route? *Every* package individually gets declared stable eventually - they don't release when the kernel, compilers and desktops all go stable. I think Tumbleweed needs to be separated into kernel and user sections. Unless I'm doing kernel-level work, I only want bug fixes / security updates in the kernel but I want the latest browsers, office tools, compilers, desktops, etc.

It's my understanding that in the current setup we can't do that - tumbleweed needs to resync every now and then to be able to roll on. Probably 'cuz big plumbing is hard to do in a rolling release. Of course that can be solved but probably not exactly in a trivial way...

On Wed, 2012-06-13 at 20:33 +0200, Jos Poortvliet wrote:

I'm entirely on the same page with you.

A 1 year release schedule and using OBS and Tumbleweed to satisfy the needs for those needing more up-to-date software seems perfect to me.

Let's be honest - if you want the latest, 6, 8 or 12 months - it's all too slow so you use Tumbleweed anyway. If you want stable, 12 months is better than 8 is better than 6. Simple.

if it happens to help our release engineering, awesome too ;-)

All very logical and I support it as well from a practical standpoint as a user. The downside of this, however, is less marketing noise. We'll only promote the release once a year instead of up to 2 times a year. We'll slip on Distrowatch (for those that care, I don't care about Distrowatch.) And while marketing may not be an issue of interest in this particular list, less noise does create less attraction to future potential contributors and developers. Not saying that's a reason we shouldn't reconsider changing our gameplan. Just putting it out there that it will be one area definitely affected (for good or bad.) Bryen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Onsdag den 13. juni 2012 20:33:08 Jos Poortvliet skrev:

On Tuesday 12 June 2012 13:41:50 M. Edward Borasky wrote: <snip>

...

If *I* were making the decision, I'd say "let Ubuntu and Fedora fight it out for the mass market and switch to the Debian / Gentoo model". Because I think that's the way openSUSE is evolving anyhow - a strong, sophisticated community of IT users and technologies like Open Build Service and OpenQA. I'm using openSUSE and not Debian or Gentoo because of that.

I'm entirely on the same page with you.

A 1 year release schedule and using OBS and Tumbleweed to satisfy the needs for those needing more up-to-date software seems perfect to me.

Let's be honest - if you want the latest, 6, 8 or 12 months - it's all too slow so you use Tumbleweed anyway. If you want stable, 12 months is better than 8 is better than 6. Simple.

if it happens to help our release engineering, awesome too ;-)

Easy for you to say since you're already not using openSUSE but rather Tumbleweed. A 12 month schedule does not automatically make it more stable, unless maybe if you also increase the various freeze periods. But that'll just make developers/packagers and testers even less interested in testing/using factory than is already the case - and move even more activity away from factory to little toy OBS projects - and hence away from the distro that actually matters. I personally think 8 months is the perfect balance. It's not clear to me what exactly has gone wrong with 12.2 anyway. In my brief tests 12.2beta seemed pretty good. Usually the beta is the worst milestone of them all, cuz it's just after feature freeze. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

You may recall a lengthy post I made concerning systemd some months back... Just to let you know, I have not installed 12.1 and am unlikely to install a 11.4+ version due to openSuSE's adoption of systemd. GKH may advise Gentoo to adopt systemd but I don't see it happening anytime soon - a bit like the decision on having /USR mounted on a separate partition... I now have several formerly-openSuSE desktop machines running Gentoo (utilising OpenRC). Meanwhile, my former OpenSuSE servers run OpenBSD. I am shifting other machines to FreeBSD. My feeling is that openSuSE has been suffering from an identity crisis for some time - dropping enterprise robustness to chase desktop performance. Meanwhile, detaching itself slowly from regular system administrators to please no doubt skilled but, on occasion, fickle developers. Developers who want to chase the stars. True, without Developers - there would be no innovation; but Developers are by their nature not too concerned with providing long-term stable architectures. That is NOT a criticism - it is an observation of how I develop my code in development circumstances - but it rarely suits users or enterprises seeking stable systems. openSuSE for me WAS a solid server and/or desktop system which while not as conservative as Debian did not rush to adopt brand new things like, say, Ubuntu and, recently, Fedora. Increasingly, however, openSuSE has followed Fedora rather than steering its own course. What seems to be happening now is that the attempt to adopt a lot of new things at once is leading to over-trading (for want of a better word) and exhaustion of the resources available (key developers and maintainers). Effort is being fragmented. The ultimate outcome leads to users and enterprises being scared-off and the burn-out of developers - hence slippage on RC1. The solution is for a guiding council to re-establish openSuSE's original mission - to provide an up-to-date but solid server and desktop environment - and select a reduced set of new developments to be adopted in one release. Consolidation of what has been gained before venturing forward anew. Changing the ethos of openSuSE by seeking to compete with OpenBSD-stable for servers, Gentoo's modularity for skilled administrators/developers, Ubuntu's/Fedora's radical desktop developments (when not provided with the resources of Canonical or Red Hat to iron out problems while keeping users happy) or the user experience of Android (cf. Win8) (when lacking Google's/Microsoft's resources) is ultimately futile. openSuSE must rediscover what originally made it a great OS - it's highly-functional reliable stability. I wish openSuSE luck because I'm afraid you have already lost me - barring a complete volte-face on certain decisions which lead openSuSE-developers are unlikely to reverse, unfortunately. Mike On 13/06/12 20:42, M. Edward (Ed) Borasky wrote:

...

Onsdag den 13. juni 2012 20:33:08 Jos Poortvliet skrev: Easy for you to say since you're already not using openSUSE but rather Tumbleweed. A 12 month schedule does not automatically make it more stable, unless maybe if you also increase the various freeze periods. But that'll just make developers/packagers and testers even less interested in testing/using factory than is already the case - and move even more activity away from factory to little toy OBS projects - and hence away from the distro that actually matters. I personally think 8 months is the perfect balance. It's not clear to me what exactly has gone wrong with 12.2 anyway. In my brief tests 12.2beta seemed pretty good. Usually the beta is the worst milestone of them all, cuz it's just after feature freeze. The 12.2 schedule took a hard hit from a pair of hard disk failures back-to-back in the OBS servers. As to the quality of the beta, I had to give up on it. KDE is crashing with known KDE bugs that send me to

On Wed, Jun 13, 2012 at 11:57 AM, Martin Schlander wrote: the upstream KDE bug tracker automatically, and GRUB2 rendered one of my machines unbootable. To be fair, Beefy Miracle's GRUB2 did the same thing on this ancient box. ;-) My current development / test cycle is centered on KDE and Fedora / OpenShift Origin, so I had to give up on 12.2 for a while. My preference would be for a Debian / Gentoo model, where stable servers are rock-solid and secure. The kernel, LXC/KVM/libvirt, Apache, MySQL, PHP, PostgreSQL, Perl/CPAN, Python/Django, Ruby/Rails/Sinatra, Java and to a lesser extent Node.js, Redis and MongoDB are what matters for servers. If all of that is stable, I say the distro is stable. Then layer everything else on top of that - compilers, desktops, productivity suites, browsers, etc. when they're stable upstream via the Tumbleweed process. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

If it wasn't clear in my earlier post - I apologise. I wasn't holding up Gentoo, OpenBSD, any alternative Linux or BSD as an universal panacea for all situations. As you can see, I am not settled on any particular platform for my systems. I am carefully selecting different OS models for each application. Meanwhile, I was seeking to indicate that each Linux/BSD has its own strengths. The problem for me is that openSuSE appears to have moved away from what I understood to be its role for ME... a distribution which is an informed adopter of new tools, modules etc. whilst ensuring that developments adopted/incorporated don't destroy the robust foundation of the distribution to the detriment of specific stakeholders - system administrators, developers and desktop users. It is my feeling that recently there has been a rush to satisfy desktop users to the detriment of system administrators and some developers... That is MY view. However, I thought it worth mentioning because I see openSuSE developers slipping on delivery due to cascading issues caused by the decision to adopt many changes all at once. Meanwhile, while previously an openSuSE advocate, I am now adopting alternatives because I feel openSuSE is moving away from my needs - and suspect I am not the only one. I felt it might be possible to communicate how I perceived openSuSE in the interest of prompting a move back towards my preferred function for the distribution. I don't have an interest in the outcome beyond a selfish desire to replace the position openSuSE formerly held for me. I am not concerned if openSuSE continues on an alternative path because I am using alternative tools to provide the necessary functionality I desire. Consequently, as I said, I wish openSuSE luck for the future - I have enjoyed using it in the past (it WAS my default distribution). Meanwhile, I will continue to monitor openSuSE development through these lists in the event there is a change - but I have to say that it will be from the safety of an alternative platform... Best regards. Mike On 14/06/12 00:21, M. Edward (Ed) Borasky wrote:

On Wed, Jun 13, 2012 at 3:26 PM, llemikebyw@aol.com wrote:

...

You may recall a lengthy post I made concerning systemd some months back...

[snip]

I came to openSUSE after Gentoo's botched community process, failed organizational time and money management and unworkable release engineering model shattered my confidence in Gentoo. At the time (mid-2008) Ubuntu, Fedora and openSUSE were all on six-month release cycles and the differences were minor. I tried Fedora first and had issues with projectors, and Ubuntu had an older kernel than openSUSE, so I went with openSUSE.

I'm still here, and IMHO there's still not a lot of difference between the three. SUSE Studio and OBS are better than anything I've seen from the other two, and the communities all seem to me to be equally strong. I wish we had a PaaS like Cloud Foundry and OpenShift Origin, and I think we could tweak the software engineering discipline a little to avoid some of the catastrophes. but over all I don't think openSUSE is as bad as you make it out to be. It's certainly nowhere near as bad as Gentoo got after they missed a foundation paperwork filing deadline and suffered six months of power struggles on the mailing lists.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I've been saying the same thing for a couple years. I'm still here because the pain of switching is high in my case, and the pain of having a mixed environment is high too, and I am skilled enough to take almost anything and make it workable myself and hide any problems from my developers and customers. But if I was switching from SCO Open Server _today_ instead of 7 or more years ago, I don't know if I'd choose Suse today (any suse). It's a different product with different prospects and no predictability at all any more. I'm not necessarily saying it's going down the tubes. It may become fine. I'm saying there is no basis to predict that today. Back when I chose opensuse, at that time there was a pretty consistent history of progress and quality assurance and version-to-version stability in how things worked, if you include "suse" before "opensuse" had that name. So for now I just continue to deal with it. Sometime, maybe not even before 12.2 comes out I will probably start installing 12.1 after I establish a good reproducible and reliable install procedure for reverting systemd, because I have too many things that _I Need_ that _don't work_ with systemd. Now I could probably figure out some way to get things all working in systemd, and rewrite all my spec files and sys admin notes and internal company knowledgebase docs for systemd, even hack some programs I don't even have the source for by wrapping them in wrapper scripts or ld preload tricks, but why should I assume the burden of doing all that? Who's going to pay my company for all that time? What benefit do I get to say we are getting for the investment? Our stuff already works the way we want it, so, ??? I'd do a lot of work just to retain functionality we already have? I can't sell that even if I was deranged enough to want to. Also there is this. Recently on the rsync bugzilla someone posted a bug because rsync exits with exit values other than 0 in some situations that are not errors. These exit values are documented and perfectly reasonable. But, systemd does not allow for _anything_ but 0=ok, everything else = failure, which screws up systemd stopping/starting the service sometimes. Systemd says rsync is wrong and should change that behavior. The behavior is documented, has been the same for decades, predates systemd by decades, and is within the designed intended use of exit values in programs since exit values even existed. Yet systemd, instead of realising that such a narrow assumption is a bug, once again decides the rest of the world is wrong and systemd is right. That tells me that I do not want to invest any time adapting anything to systemd, because it's too much of a one way street. Systemd will not adapt to provide me with a powerful tool that can handle any possible situation, systemd requires me to adapt everything else to get it to work at all, or live without anything I can't adapt. That is not why I run a unix-like OS. I run a unix-like OS because it is flexible and I can configure it to do whatever unpredictable unusual _I_ need it to do. Unix is not a machine that does a job, it's a tool box that you build any machine you might need to do any job you might need. Systemd, at least until it changes it's stance, and especially when you remember it's aiming to take over at least the jobs of cron and udev as well, is only good for more narrowly defined systems like embedded systems and appliances, Android, and typical desktops. The logical extension of the systemd path is to include the kernel, systemd and busybox all in one binary, and that's you're entire OS, all else is user/application. Sure it would be fast and efficient. And a neat experiment. And a handy system-on-a-stick for some special cases. And useless for me. 12.2? who knows. If it's still relatively simple to block systemd and keep sysv init in 12.2 then I'll probably end up still using suse during 12.2. Then again who knows, because systemd is just one example not the only issue. And the devs here don't want to hear any of this. And that's just another part of the problem. -- bkw On 6/13/2012 9:13 PM, llemikebyw@aol.com wrote:

If it wasn't clear in my earlier post - I apologise.

I wasn't holding up Gentoo, OpenBSD, any alternative Linux or BSD as an universal panacea for all situations. As you can see, I am not settled on any particular platform for my systems. I am carefully selecting different OS models for each application.

Meanwhile, I was seeking to indicate that each Linux/BSD has its own strengths.

The problem for me is that openSuSE appears to have moved away from what I understood to be its role for ME... a distribution which is an informed adopter of new tools, modules etc. whilst ensuring that developments adopted/incorporated don't destroy the robust foundation of the distribution to the detriment of specific stakeholders - system administrators, developers and desktop users.

It is my feeling that recently there has been a rush to satisfy desktop users to the detriment of system administrators and some developers...

That is MY view.

However, I thought it worth mentioning because I see openSuSE developers slipping on delivery due to cascading issues caused by the decision to adopt many changes all at once.

Meanwhile, while previously an openSuSE advocate, I am now adopting alternatives because I feel openSuSE is moving away from my needs - and suspect I am not the only one.

I felt it might be possible to communicate how I perceived openSuSE in the interest of prompting a move back towards my preferred function for the distribution.

I don't have an interest in the outcome beyond a selfish desire to replace the position openSuSE formerly held for me.

I am not concerned if openSuSE continues on an alternative path because I am using alternative tools to provide the necessary functionality I desire.

Consequently, as I said, I wish openSuSE luck for the future - I have enjoyed using it in the past (it WAS my default distribution).

Meanwhile, I will continue to monitor openSuSE development through these lists in the event there is a change - but I have to say that it will be from the safety of an alternative platform...

Best regards.

Mike

On 14/06/12 00:21, M. Edward (Ed) Borasky wrote:

...

On Wed, Jun 13, 2012 at 3:26 PM, llemikebyw@aol.com wrote:

...

You may recall a lengthy post I made concerning systemd some months back...

[snip]

I came to openSUSE after Gentoo's botched community process, failed organizational time and money management and unworkable release engineering model shattered my confidence in Gentoo. At the time (mid-2008) Ubuntu, Fedora and openSUSE were all on six-month release cycles and the differences were minor. I tried Fedora first and had issues with projectors, and Ubuntu had an older kernel than openSUSE, so I went with openSUSE.

I'm still here, and IMHO there's still not a lot of difference between the three. SUSE Studio and OBS are better than anything I've seen from the other two, and the communities all seem to me to be equally strong. I wish we had a PaaS like Cloud Foundry and OpenShift Origin, and I think we could tweak the software engineering discipline a little to avoid some of the catastrophes. but over all I don't think openSUSE is as bad as you make it out to be. It's certainly nowhere near as bad as Gentoo got after they missed a foundation paperwork filing deadline and suffered six months of power struggles on the mailing lists.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 14 of June 2012 14:03EN, Brian K. White wrote:

12.2? who knows. If it's still relatively simple to block systemd and keep sysv init in 12.2 then I'll probably end up still using suse during 12.2.

Fortunately it is the same as in 12.1, just replace systemd-sysvinit package by sysvinit-init. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 16 of June 2012 03:20EN, Felix Miata wrote:

Don't be so sure. It would come as no surprise to me if sysvinit-init bugs like https://bugzilla.novell.com/show_bug.cgi?id=766035 don't get any attention prior to 12.2 release, if ever.

IMHO the main problem here is it being auto-assigned to nld10-bugs- qa@forge.provo.novell.com which is probably just a fancy alias for a black hole. I already noticed these issues but haven't found time to investigate them properly because of more severe bugs. I hope I'll get to it later this week. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 15/06/12 04:03, Brian K. White wrote:

I've been saying the same thing for a couple years.

I'm still here because the pain of switching is high in my case, and the pain of having a mixed environment is high too, and I am skilled enough to take almost anything and make it workable myself and hide any problems from my developers and customers.

But if I was switching from SCO Open Server _today_ instead of 7 or more years ago, I don't know if I'd choose Suse today (any suse). It's a different product with different prospects and no predictability at all any more. I'm not necessarily saying it's going down the tubes. It may become fine. I'm saying there is no basis to predict that today. Back when I chose opensuse, at that time there was a pretty consistent history of progress and quality assurance and version-to-version stability in how things worked, if you include "suse" before "opensuse" had that name.

So for now I just continue to deal with it. Sometime, maybe not even before 12.2 comes out I will probably start installing 12.1 after I establish a good reproducible and reliable install procedure for reverting systemd, because I have too many things that _I Need_ that _don't work_ with systemd.

Now I could probably figure out some way to get things all working in systemd, and rewrite all my spec files and sys admin notes and internal company knowledgebase docs for systemd, even hack some programs I don't even have the source for by wrapping them in wrapper scripts or ld preload tricks, but why should I assume the burden of doing all that? Who's going to pay my company for all that time? What benefit do I get to say we are getting for the investment? Our stuff already works the way we want it, so, ??? I'd do a lot of work just to retain functionality we already have? I can't sell that even if I was deranged enough to want to.

Also there is this. Recently on the rsync bugzilla someone posted a bug because rsync exits with exit values other than 0 in some situations that are not errors. These exit values are documented and perfectly reasonable. But, systemd does not allow for _anything_ but 0=ok, everything else = failure, which screws up systemd stopping/starting the service sometimes. Systemd says rsync is wrong and should change that behavior. The behavior is documented, has been the same for decades, predates systemd by decades, and is within the designed intended use of exit values in programs since exit values even existed. Yet systemd, instead of realising that such a narrow assumption is a bug, once again decides the rest of the world is wrong and systemd is right. That tells me that I do not want to invest any time adapting anything to systemd, because it's too much of a one way street. Systemd will not adapt to provide me with a powerful tool that can handle any possible situation, systemd requires me to adapt everything else to get it to work at all, or live without anything I can't adapt.

That is not why I run a unix-like OS.

I run a unix-like OS because it is flexible and I can configure it to do whatever unpredictable unusual _I_ need it to do. Unix is not a machine that does a job, it's a tool box that you build any machine you might need to do any job you might need.

Systemd, at least until it changes it's stance, and especially when you remember it's aiming to take over at least the jobs of cron and udev as well, is only good for more narrowly defined systems like embedded systems and appliances, Android, and typical desktops. The logical extension of the systemd path is to include the kernel, systemd and busybox all in one binary, and that's you're entire OS, all else is user/application. Sure it would be fast and efficient. And a neat experiment. And a handy system-on-a-stick for some special cases. And useless for me.

12.2? who knows. If it's still relatively simple to block systemd and keep sysv init in 12.2 then I'll probably end up still using suse during 12.2. Then again who knows, because systemd is just one example not the only issue.

And the devs here don't want to hear any of this. And that's just another part of the problem.

CLAP! CLAP! CLAP! Bravo! Very well put, Brian! I chose SuSE way back when for exactly the same reasons you state in para 3 above. BC -- Using openSUSE 12.1 x86_64 KDE 4.8.3 and kernel 3.4.2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-06-16 15:02, Stefan Seyfried wrote:

Am 16.06.2012 08:14, schrieb Basil Chupin:

...

On 15/06/12 04:03, Brian K. White wrote:

...

...

And the devs here don't want to hear any of this. And that's just another part of the problem.

CLAP! CLAP! CLAP! Bravo!

The fix is easy. Get enough devs that are interested to hear any of this and work on fixing it like you want it.

If there would be enough manpower to maintain (e.g.) lots of different init systems, then that would be no problem. It's not impossible,just "somebody" needs to do the work.

Devs should not do what they love to do, but what has to be done, like it or not. As I do in my field of collaboration. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/c8QQACgkQIvFNjefEBxrFWACgsxDd5dFNQOMTGjWNX/tU9J72 FCUAn3rEx2X1QkuEWKAd0hW51YBxXBuT =/XbH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 16 June 2012 22:48:04 Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2012-06-16 15:02, Stefan Seyfried wrote:

...

Am 16.06.2012 08:14, schrieb Basil Chupin:

...

On 15/06/12 04:03, Brian K. White wrote:

...

And the devs here don't want to hear any of this. And that's just another part of the problem.

CLAP! CLAP! CLAP! Bravo!

The fix is easy. Get enough devs that are interested to hear any of this and work on fixing it like you want it.

If there would be enough manpower to maintain (e.g.) lots of different init systems, then that would be no problem. It's not impossible,just "somebody" needs to do the work.

Devs should not do what they love to do, but what has to be done, like it or not.

As I do in my field of collaboration.

To the extend that people feel responsible (and don't get get turned of by complainers), yes, they work on what they deem important. But that still doesn't mean anyone can tell them what to do. But if you need something from systemd that it can't do, you can create a feature request for it: https://bugs.freedesktop.org/enter_bug.cgi?product=systemd Maybe one of the developers can write the feature you want. If it really is an important/much requested feature, it's likely they'll do it at some point. Note that if what you want can be done with systemd but just not exactly the way you want, you can expect Lennart to make fun of you and insult you for being a stubborn dickhead and not willing to change and adopt to a New World™. Whether that makes him a dick or you an stubborn idiot depends (in a very relativistic way) on the observer and seems to have little relationship with reality (other than that progress can't be stopped and usually Lennart gets what he wants, like it or not). But you know all that, right? /Jos

- -- Cheers / Saludos,

Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/c8QQACgkQIvFNjefEBxrFWACgsxDd5dFNQOMTGjWNX/tU9J72 FCUAn3rEx2X1QkuEWKAd0hW51YBxXBuT =/XbH -----END PGP SIGNATURE-----

On 16/06/12 23:02, Stefan Seyfried wrote:

Am 16.06.2012 08:14, schrieb Basil Chupin:

...

On 15/06/12 04:03, Brian K. White wrote:

...

And the devs here don't want to hear any of this. And that's just another part of the problem.

CLAP! CLAP! CLAP! Bravo! The fix is easy. Get enough devs that are interested to hear any of this and work on fixing it like you want it.

If there would be enough manpower to maintain (e.g.) lots of different init systems, then that would be no problem. It's not impossible,just "somebody" needs to do the work.

I am certainly not downplaying the role of developers and, in fact, I admire them and actually envy them because they have the skills which I lack to do what they are doing. However, when there is no clear goal or direction then the effort put into a project by such capable people may not be used efficiently and in fact may be a waste of time and effort as well as being detrimental to the distribution which they are trying to support. BC -- Using openSUSE 12.1 x86_64 KDE 4.8.4 and kernel 3.4.3 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 13.06.2012 20:57, schrieb Martin Schlander:

Easy for you to say since you're already not using openSUSE but rather Tumbleweed.

A 12 month schedule does not automatically make it more stable, unless maybe if you also increase the various freeze periods. But that'll just make developers/packagers and testers even less interested in testing/using factory than is already the case - and move even more activity away from factory to little toy OBS projects - and hence away from the distro that actually matters.

That's a true danger - but if you see Tumbleweed as part of the distro strategy, it can very well work out.

I personally think 8 months is the perfect balance. It's not clear to me what exactly has gone wrong with 12.2 anyway. In my brief tests 12.2beta seemed pretty good. Usually the beta is the worst milestone of them all, cuz it's just after feature freeze.

The biggest problem with 12.2 right now is that we can't slip a bit. Mid of july just does not allow slips ;( And that again is a problem of 8 months, there are just not 3 good times a year ;) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 13.06.2012 22:22, schrieb Bryen M Yunashko:

On Wed, 2012-06-13 at 22:14 +0200, Stephan Kulow wrote:

...

The biggest problem with 12.2 right now is that we can't slip a bit. Mid of july just does not allow slips ;( And that again is a problem of 8 months, there are just not 3 good times a year ;)

Personally, I've always felt May-January-September would have made more sense for an 8 month release cycle. But as you point out, I guess that would be debatable as well. :-)

Yeah, because you obviously didn't notice that december is a lost month even on our lists. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Jun 13, 2012 at 08:33:08PM +0200, Jos Poortvliet wrote:

On Tuesday 12 June 2012 13:41:50 M. Edward Borasky wrote: <snip>

...

If *I* were making the decision, I'd say "let Ubuntu and Fedora fight it out for the mass market and switch to the Debian / Gentoo model". Because I think that's the way openSUSE is evolving anyhow - a strong, sophisticated community of IT users and technologies like Open Build Service and OpenQA. I'm using openSUSE and not Debian or Gentoo because of that.

I'm entirely on the same page with you.

A 1 year release schedule and using OBS and Tumbleweed to satisfy the needs for those needing more up-to-date software seems perfect to me.

That's fine with me, but then I might need a bit more help with Tumbleweed if that were to happen :) greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2012/06/12 13:36 (GMT-0500) Bryen M Yunashko composed:

Perhaps we should remove the "18-month Rule" and re-define it as "N-2 gets support always until 2 months after most current version is released"?

+1 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11.06.2012 17:49, Cristian Rodríguez wrote:

El 11/06/12 04:34, Stephan Kulow escribió:

...

Hi,

It's monday morning and I can't see how we can finish RC1 this week - seriously, I can't even see how we can do it this month ;(

OK, then let's delay this thing until the blocking/mayor bugs are fixed. 2 weeks delay isnt a big deal anyway.

No, it's not - if you live on the southern hermisphere where it's just winter. Releasing early august is something we can just as well skip as long as our main audience will have vacation. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 12 June 2012 10:34:28 Henne Vogelsang wrote:

Hey,

On 06/11/2012 05:51 PM, Stephan Kulow wrote:

...

On 11.06.2012 17:49, Cristian Rodríguez wrote:

...

El 11/06/12 04:34, Stephan Kulow escribió:

...

Hi,

It's monday morning and I can't see how we can finish RC1 this week - seriously, I can't even see how we can do it this month ;(

OK, then let's delay this thing until the blocking/mayor bugs are fixed. 2 weeks delay isnt a big deal anyway.

No, it's not - if you live on the southern hermisphere where it's just winter. Releasing early august is something we can just as well skip as long as our main audience will have vacation.

Okay so what is your proposal? :)

Sounds like he means skipping a release... ;-)

Henne

2012/6/11 Guido Berhoerster :

On 11.06.2012 17:49, Cristian Rodríguez wrote:

...

El 11/06/12 04:34, Stephan Kulow escribió:

...

Hi,

It's monday morning and I can't see how we can finish RC1 this week - seriously, I can't even see how we can do it this month ;(

OK, then let's delay this thing until the blocking/mayor bugs are fixed. 2 weeks delay isnt a big deal anyway.

That doesn't seem sensible since there are likely blocking/major bugs which are not even known at this point due to the YaST-zypper brokenness that has made it very difficult for many people to even test Factory.

A little workaround for the YaST-zypper brokenness, is to use zypper in console. Other problem is that the Yast Software Management ncurses module do'nt open. I makes the update, but do'nt open the screen for install/update or remove software. Regards, Juan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org