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 ;( Most annoying bug nr. 1 is fixed since yesterday (hopefully), but the crash with /usr is still there and hasn't seen activity for 14 days ;( bnc#752796 The live cd I almost got back in shape by - you guessed it - removing a whole bunch of packages. Working DVDs we could not yet produce though. I spent a fair share of the weekend to get texlive back in shape for factory, but I have 120 failing packages - webyast and the go stack being biggest offenders in numbers. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Monday 11 June 2012 10:34:33 Stephan Kulow wrote:
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 ;(
Most annoying bug nr. 1 is fixed since yesterday (hopefully), but the crash with /usr is still there and hasn't seen activity for 14 days ;( bnc#752796
Well, with zypper/yast/whatever crashing as soon as there's a conflict to solve, I'm not sure 12.2 meets the RC minimum quality. root@yuuko:~ # YaST got signal 11 at YCP file PackagesUI.ycp:280 /sbin/yast2: line 427: 5225 Segmentation fault (core dumped) $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS # rpm -qi libzypp Name : libzypp Version : 11.6.1 # rpm -qi yast2-core Name : yast2-core Version : 2.23.0 root@yuuko:/cores # file core.y2base.5225 core.y2base.5225: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4- style, from '/usr/lib/YaST2/bin/y2base sw_single qt' Backtrace: http://paste.opensuse.org/view/raw/77039501 Valgrind log: http://paste.opensuse.org/view/raw/36206815 Christophe
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/6/11 Stephan Kulow <coolo@suse.de>:
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
Yeah - I'm struggling with the beta myself. Between GRUB2 messing up my dual-boot on one machine and random upstream KDE crashes sending me to the KDE bug reporting system, the beta is a mess. I've run into the YaST2 segfaults too but that's not a show-stopper for me. I was just going to post a question to the list about what to do about the KDE crashes. I assume I should post something to the openSUSE Bugzilla but these are listed in KDE's tracker as known issues. If there's a slip till September/October can that get a UEFI workaround into the release? Is there even a way to test against UEFI now? On Mon, Jun 11, 2012 at 2:52 AM, Stephan Kulow <coolo@suse.de> wrote:
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
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- 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 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
* Bryen M Yunashko <suserocks@bryen.com> [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
On Tue, Jun 12, 2012 at 11:44 AM, Patrick Shanahan <paka@opensuse.org> wrote:
* Bryen M Yunashko <suserocks@bryen.com> [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, 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. Bryen
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.
-- 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, 2012-06-12 at 22:38 +0200, Marcus Meissner wrote:
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
I had assumed that 18-months was the stated rule, as it is the line we use widely everywhere. From what you're telling me, it is actually a de facto effect in which we conveniently applied the 18-month statement because that is what usually happens for our releases. In which case, my proposal here is moot, since it already exists in form. We shoud probably work better at making the N-2/2month rule clearer to everyone (including marketing team.) I withdraw my unnecessary proposal. :-) Apologies and thanks for clarifying. Bryen -- 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 <suserocks@bryen.com> 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 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 ;-)
On Wed, Jun 13, 2012 at 11:33 AM, Jos Poortvliet <jos@opensuse.org> 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 Wed, 2012-06-13 at 11:41 -0700, M. Edward (Ed) Borasky wrote:
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.
Hmm, now that you mention desktops... I recall that we've had a bit of difficulty putting out a stable GNOME 3.4 under the current 12.1. For backporting reasons I'm not entirely understanding, its advised to just wait for 12.2 to come out and get GNOME 3.4 then. (At least I was told that a month ago.) For some reason, I guess, 12.1 and 3.4 aren't liking each other very much. :-) I wonder what would happen if we turned to once-a-year releases if we are to rely on ourselves to get the latest/greatest via OBS. Bryen -- 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 <jos@opensuse.org> 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 Thu, Jun 14, 2012 at 08:17:39AM +0200, Jos Poortvliet wrote:
On Wednesday 13 June 2012 11:41:28 M. Edward Borasky wrote:
On Wed, Jun 13, 2012 at 11:33 AM, Jos Poortvliet <jos@opensuse.org> 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.
big plumbing isn't the difficult part, it's the "let's replace the complier and watch everything break" that is the hard part. And, when the low-level system dependancies change, the whole distro wants to rebuild, taking a few days to complete just to see if anything broke or not. But that all can be resolved, it's not that difficult, you just will have days when all of your packages want to upgrade :) greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
On Wed, Jun 13, 2012 at 11:44 AM, Bryen M Yunashko <suserocks@bryen.com> wrote:
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
Marketing is about budgets and key performance indicators and strategy, not about release cycles. Debian, CentOS and Ubuntu still rule the roost in community distros for servers and I'm not sure what the breakdowns are for supported corporate servers between RHEL, SLES, Oracle and Canonical. I don't think Linux desktops are even two percent of the total desktop / laptop market - Windows and Mac are the only significant ones there. My blog is open-source oriented and most of my traffic comes from Windows and Macs running Firefox and Chrome and iPads and iPhones running "Safari" - Linux, Internet Explorer and Android are irrelevant. And I don't think there are a lot of Fedora or openSUSE servers. My own use case is highly unusual - the best description would be "scientific workstation". I've run Windows 2000 - XP - Vista - 7 dual-booted with Red Hat 6.2 / 7 / 8 / 9 / Debian / Gentoo / openSUSE for the past 12 years and never looked back. But in any case I'm hardly representative of a strategic market segment like servers. I think openSUSE would do better in the markets that actually matter - servers - if we had solid Infrastructure as a Service and Platform as a Service offerings. We *do* have B1 Systems' OpenStack Essex in the OBS repos, but I think the documentation is still German only and only people like me who track that stuff have even heard of B1 Systems. We don't have an open source Platform as a Service like VMware's Cloud Foundry or Red Hat's OpenShift Origin. Neither of those appears to be difficult to port to openSUSE, although I think OpenShift's Fedora 16 / RHEL 6 RPMs are less work than CloudFoundry's Ubuntu 10.04 .debs. But I think we should have our own, leveraging off of WebYast, SUSE Studio and OBS. -- 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
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
On Wed, Jun 13, 2012 at 11:57 AM, Martin Schlander <martin.schlander@gmail.com> 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 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. -- 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
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:
On Wed, Jun 13, 2012 at 11:57 AM, Martin Schlander <martin.schlander@gmail.com> 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 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
On Wed, Jun 13, 2012 at 3:26 PM, llemikebyw@aol.com <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. -- 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
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<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 Wed, Jun 13, 2012 at 6:13 PM, llemikebyw@aol.com <llemikebyw@aol.com> wrote:
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.
That was my first thought too, after years of hard-won lessons in software engineering and project management, starting from "The Mythical Man-Month". But there were also two severe hard disk crashes, and openSUSE isn't the only distro that's slipped a date recently - Fedora's "Beefy Miracle" took three one-week slips for show-stopper bugs as I recall. Community distros *want* to be on the bleeding edge relative to, say, SLE, RHEL or Debian Stable.
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.
My only frustrations with openSUSE at the moment are in the area of IaaS and PaaS. I wish we had something like Cloud Foundry or OpenShift Origin in 12.2, and I'm not about to wait another 8-month release cycle to get a PaaS - I'm going to migrate that project to Fedora / OpenShift Origin. But that's hardly a desire for a "stable server" - it's a desire for a bleeding edge gizmo that Fedora has and openSUSE doesn't. -- 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
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<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 Thu, Jun 14, 2012 at 02:03:05PM -0400, Brian K. White wrote:
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.
Why would you ever use a 'raw' rsync call as a system service that systemd would want to run? Surely you would properly wrap it to handle the different types of errors that rsync can produce, right? Anyway, that's way off topic here, we understand you don't like systemd, and that's sad, but there are always other distros, that for today, are not upgrading. Nothing is set in stone for forever though, I place bets on everyone moving in the next 5 years :) good luck, greg k-h -- 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 2012/06/15 11:27 (GMT+0200) Michal Kubeček composed:
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.
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. -- "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 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 Tuesday, June 19, 2012 09:33:13 Michal Kubeček wrote:
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.
The assignments were an error, they will be fixed now, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- 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
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. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- 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 Sat, 16 Jun 2012 22:48:04 +0200, "Carlos E. R." <carlos.e.r@opensuse.org> wrote:
Devs should not do what they love to do, but what has to be done, like it or not.
And rest assured they. But for most of the SUSE developers (except the SUSE boosters folk) maintaining packages, work on SLES is top priority. Philipp -- 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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-06-19 13:27, Jos Poortvliet wrote:
On Saturday 16 June 2012 22:48:04 Carlos E. R. wrote:
But if you need something from systemd that it can't do, you can create a
I was not pointing to systemd specifically.
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
No, I deny his right to insult me. Not him, not you, not anybody. - -- 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/ iEUEARECAAYFAk/gcCcACgkQIvFNjefEBxp9TQCWNd9lEHe1yeGAwxDmLwiy1A+4 kQCgjLyZ8DG5BS868Xp2zZBg64CH8kk= =5v9k -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-06-21 09:28, Basil Chupin wrote:
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.
Exactly... - -- 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/i288ACgkQIvFNjefEBxrT1gCgppVonDhOgA4Gy+UI6NNFkbEj Dx0AmgNRtb4tkSCRRLGq+iO71Uqx9fLK =dDwc -----END PGP SIGNATURE----- -- 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
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. :-) Bryen -- 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 Wednesday 13 June 2012 20:57:21 Martin Schlander wrote:
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.
As Coolo already said, this might be mitigated by making Tumbleweed a more integral part of how we work. Moreover, I absolutely agree that our distro gets not automatically more stable with a longer release cycle. Increasing the freezes and being even more conservative would, for me, certainly be part of this plan. Basically, we move openSUSE even more in the direction of a stable and slightly boring workhorse, while the 'cool' stuff happens in OBS repo's and Tumbleweed - all feeding back to the new stable release once a year.
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.
There's certainly something wrong but I guess this is something Coolo can better address than I can.
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
Am 13.06.2012 21:00, schrieb Greg KH:
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 :)
For sure :) Greetings, Stephan -- 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
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. -- 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
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? :) Henne -- Henne Vogelsang, openSUSE http://www.hennevogel.de Everybody has a plan, until they get hit. - Mike Tyson -- 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
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. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/6/11 Guido Berhoerster <gber@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.
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
On 06/11/2012 12:41 PM, Juan Erbes wrote:
2012/6/11 Guido Berhoerster<gber@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.
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
If things are so broken. Why not push it back to August 11th :-) If I had programming skills I would be helping you all out in the thick of things. However, I have a lot of time on hand for testing, reporting and writing. ;-) Cheers! Roman --------------------------------------------------------------- openSUSE -- Get it! Discover it! Share it! --------------------------------------------------------------- http://linuxcounter.net/ #179293 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (23)
-
Andreas Jaeger -
Basil Chupin -
Brian K. White -
Bryen M Yunashko -
Carlos E. R. -
Christophe Giboudeaux -
Cristian Rodríguez -
Felix Miata -
Greg KH -
Guido Berhoerster -
Henne Vogelsang -
Jos Poortvliet -
Juan Erbes -
llemikebyw＠aol.com -
M. Edward (Ed) Borasky -
Marcus Meissner -
Martin Schlander -
Michal Kubeček -
Patrick Shanahan -
Philipp Thomas -
Roman Bysh -
Stefan Seyfried -
Stephan Kulow