[opensuse-project] Organization of SW releases
Hi all, There is discussions ongoing for the schedule of 11.2 and there is always the connection to this and that big project. Is it not possible to rearrange the distro release so that we are not depending upon these release dates? Would it be possible to have multiple levels of SW with different kinds of release regimes? The basic level would then be the operating system, and that would define the naming of the release. So the release of the openSUSE 11.2 is connected to a specific kernel. Then the desktop environments can be released and updated towards this release whenever they are ready and needed. Like now, KDE 4.2 should be made available to all users using openSUSE11.1 as soon as it's cleared factory testing and openSUSE patching. Then again applications can be released based upon build service projects and feedback from users, maybe a voting system where there is a need for a qualified number of votes stating this app is ready for update. With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level. There are maybe technical hurdles, bandwidth considerations etc. ? (Taking on my flame protective gear...) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 03 Feb 2009, Birger Kollstrand wrote:
Would it be possible to have multiple levels of SW with different kinds of release regimes?
The basic level would then be the operating system, and that would define the naming of the release. So the release of the openSUSE 11.2 is connected to a specific kernel.
Then the desktop environments can be released and updated towards this release whenever they are ready and needed. Like now, KDE 4.2 should be made available to all users using openSUSE11.1 as soon as it's cleared factory testing and openSUSE patching.
This makes sense, but from my perspective there is one change in viewpoint. I'dsuggest the release roadmaps are based around what can be done with the release rather than what software is in it. So it could be the target for a release to support (amongst other things) synchronisation with a range of PDAs or some such. A desktop is just a platform on which these useful things are built, so is necessary to support this, not an end in itself. It's only software developers who care about what packages or versions are included. Everybody else whats to do something with the software. That said, each release should preserve what was working before. Often new releases break stuff the developer wasn't interested in (and the people who are happy with the old functionality don't test the new as they don't need it). David -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, Feb 4, 2009 at 8:43 AM, Birger Kollstrand
Hi all,
There is discussions ongoing for the schedule of 11.2 and there is always the connection to this and that big project.
Is it not possible to rearrange the distro release so that we are not depending upon these release dates?
Would it be possible to have multiple levels of SW with different kinds of release regimes?
The basic level would then be the operating system, and that would define the naming of the release. So the release of the openSUSE 11.2 is connected to a specific kernel.
Then the desktop environments can be released and updated towards this release whenever they are ready and needed. Like now, KDE 4.2 should be made available to all users using openSUSE11.1 as soon as it's cleared factory testing and openSUSE patching.
Then again applications can be released based upon build service projects and feedback from users, maybe a voting system where there is a need for a qualified number of votes stating this app is ready for update.
With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.
There are maybe technical hurdles, bandwidth considerations etc. ?
(Taking on my flame protective gear...)
I'm a big fan of a rolling-release (done properly, so it's not painful / annoying) and/or having an independent release cycle for the "core system". It's a much more natural way of doing things/testing, and will give us a real edge over the competing distros. I believe there are some technical issues (proper upgrading?) but motivated primarily by marketing reasons (hard to market something with minor changes) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 03 February 2009 23:43:41 Birger Kollstrand wrote:
Hi all,
There is discussions ongoing for the schedule of 11.2 and there is always the connection to this and that big project.
Is it not possible to rearrange the distro release so that we are not depending upon these release dates?
Would it be possible to have multiple levels of SW with different kinds of release regimes?
The basic level would then be the operating system, and that would define the naming of the release. So the release of the openSUSE 11.2 is connected to a specific kernel.
Then the desktop environments can be released and updated towards this release whenever they are ready and needed. Like now, KDE 4.2 should be made available to all users using openSUSE11.1 as soon as it's cleared factory testing and openSUSE patching.
Then again applications can be released based upon build service projects and feedback from users, maybe a voting system where there is a need for a qualified number of votes stating this app is ready for update.
With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.
There are maybe technical hurdles, bandwidth considerations etc. ?
I have the following questions: * How and when to release media? * Even if you update the base system, you might need to update the desktops so that they work together. * How would a sample release schedule work? (without dates)
(Taking on my flame protective gear...)
Hope that's not needed ;). We do need some out-of-the-box thinking... Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tuesday 03 February 2009, Birger Kollstrand wrote:
With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.
Is there an example where such a release mechanism is successfully used?
--
Cornelius Schumacher
With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.
Is there an example where such a release mechanism is successfully used?
Gentoo? Kinda sorta. If a Gentoo box is updated with an emerge world (or something less dramatic) it is updated to the latest rolling releases... C. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, Feb 4, 2009 at 7:56 PM, Cornelius Schumacher
On Tuesday 03 February 2009, Birger Kollstrand wrote:
With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.
Is there an example where such a release mechanism is successfully used?
Debian (unstable) and Gentoo have something pretty similar. And freebsd (and the other bsds?) have a rolling release for their packages. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/4 Cornelius Schumacher
On Tuesday 03 February 2009, Birger Kollstrand wrote:
With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.
Is there an example where such a release mechanism is successfully used?
Let's just move to the well proven Debian model then, but without the pedantry. Then you have, Ubuntu & Fedora using 6 monthly time based releases and openSUSE being different (not just slower). openSUSE installer + ISO's can then be released, when the stable version would benefit from new packages (ie the testing version is solid). As it stands, all the incentives are towards "free loading", letting other ppl doing the testing, and it's hard work to get closer to the development versions. Actually receiving & seeing fixes as they're done, rather than waiting till install of new released version favours participation more. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, Feb 4, 2009 at 8:24 PM, Rob OpenSuSE
2009/2/4 Cornelius Schumacher
: On Tuesday 03 February 2009, Birger Kollstrand wrote:
With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.
Is there an example where such a release mechanism is successfully used?
Let's just move to the well proven Debian model then, but without the pedantry. Then you have, Ubuntu & Fedora using 6 monthly time based releases and openSUSE being different (not just slower).
openSUSE installer + ISO's can then be released, when the stable version would benefit from new packages (ie the testing version is solid).
As it stands, all the incentives are towards "free loading", letting other ppl doing the testing, and it's hard work to get closer to the development versions. Actually receiving & seeing fixes as they're done, rather than waiting till install of new released version favours participation more.
Absolutely. However, we do need a better (read: great) way of catering for users who do not wish to be part of said feature/major upgrade cycle (on a package and a system level). -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/4 Eric Springer
On Wed, Feb 4, 2009 at 8:24 PM, Rob OpenSuSE
wrote:
As it stands, all the incentives are towards "free loading", letting other ppl doing the testing, and it's hard work to get closer to the development versions. Actually receiving & seeing fixes as they're done, rather than waiting till install of new released version favours participation more.
Absolutely. However, we do need a better (read: great) way of catering for users who do not wish to be part of said feature/major upgrade cycle (on a package and a system level).
Well Debian stable, is a security and serious bug fix only version, really it's very similar in concept to running 10.3 or 11.0 now, rather than the new fangled 11.1. Those who want to avoid an unplanned upgrade would simply use "etch" in their sources list. What happens in a release is policy, not inevitably decided as a consequence of technical decisions. Possibly you could by default enable and automatic weekly update for critical fixes, and at "End of Life" warn user of unsupported status on the Login page, may be suggest switch to SLE like terms, if they want extended support, rather than upgrade. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/4 Andreas Jaeger
On Tuesday 03 February 2009 23:43:41 Birger Kollstrand wrote:
Hi all,
There is discussions ongoing for the schedule of 11.2 and there is always the connection to this and that big project.
Is it not possible to rearrange the distro release so that we are not depending upon these release dates?
Would it be possible to have multiple levels of SW with different kinds of release regimes?
The basic level would then be the operating system, and that would define the naming of the release. So the release of the openSUSE 11.2 is connected to a specific kernel.
Then the desktop environments can be released and updated towards this release whenever they are ready and needed. Like now, KDE 4.2 should be made available to all users using openSUSE11.1 as soon as it's cleared factory testing and openSUSE patching.
Then again applications can be released based upon build service projects and feedback from users, maybe a voting system where there is a need for a qualified number of votes stating this app is ready for update.
With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level.
There are maybe technical hurdles, bandwidth considerations etc. ?
I have the following questions: * How and when to release media? * Even if you update the base system, you might need to update the desktops so that they work together. * How would a sample release schedule work? (without dates)
First to Eric, my experience is that to get the safest upgrade path it's easiest to take all releases. It can be problematic to skip releases in upgrades as the developer needs to limit the upgrade paths to be able to maintain it. Regarding media release, my view on that is that each time there is a decision to move to a new kernel revision 2.26 to say 2.28 then a new media release is made with the latest set of DE's that is in the rolling releases and similarly with the packaged applications. Regarding other base sw than kernel, I think that they should go in to a controlled rolling release. But I'm on thin ice here as I do not have a good view of what would be considered base tech. So sample release schedule: - alpha1 pick kernel and add baseline base tech, base DE's and run tests - alpha2 adapt DE, yast and other distro specific patches and test - alpha3 add "voted" releases of applications and test - beta 1 update with patches and updated voted apps - if lots of probs, add beta x - RC1 , frees the baseline, only patches - Release 11.2 - start rolling release on 11.1 - beta 1 of 11.1.1 add new "voted" sw - rc1 - release 11.1.1 - beta 1 of 11.1.2 with new "voted" sw . . . . - alpha1 pick new kernel and add baseline base tech, base DE's and run tests - alpha2 adapt DE, yast and other distro specific patches and test - alpha3 add "voted" releases of applications and test - beta 1 update with patches and updated voted apps - if lots of probs, add beta x - RC1 , frees the baseline, only patches - Release 11.3 . and so on.... . . This is then based upon that the previous release was rolling and the delta is relatively small. Birger -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Clayton escribió:
With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level. Is there an example where such a release mechanism is successfully used?
Gentoo? Kinda sorta.
He said successfully... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/6 Cristian Rodriguez
Clayton escribió:
With this semi rolling release I think it would make scheduling easier and also easier to keep the user base on a more common release level. Is there an example where such a release mechanism is successfully used?
Gentoo? Kinda sorta.
He said successfully...
So we're happy to just play safe, not discuss different models that might solve the real issues that are apparent? There just seems to be a general FUD about change. So for example "zypper dup" was there, but in 11.1 we don't commit solid behind it, and now for 11.2 in the fate entry, noone seems to be really sure what work needs to be done to make it "just work" for most end users. The fast 6 month time release of Ubuntu & Fedora, with LTS & CentOS as no fee stable alternatives, does give end users a way to avoid bleeding edge, and move to a stable system with out subscription charges for security updates. 10.3 had a long release cycle, it also appears to me to have been highly unstable, until a few months after release. 11.0 & 11.1 released after fairly short time, and it was clear the majority did not want that either. There's a big danger, that openSUSE will look staler and staler, and that we don't address the perceived quality issues, before the grand release. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, 3 Feb 2009, Birger Kollstrand wrote:
The basic level would then be the operating system, and that would define the naming of the release. So the release of the openSUSE 11.2 is connected to a specific kernel.
As some of us tend to say, the kernel tends to be overrated. ;-) Yes, it provides the name to Linux or GNU/Linux, if you will, but from a desktop user perspective, for example, I should hardly notice if the kernel changes whereas an update to Firefox, OpenOffice or the desktop environment of choice is much more noticably and possibly distracting. You idea as such is interesting, though! I guess I'd just move what you call "basic level" a bit upwards and potentially give more leeway on the kernel side. (The toolchain and glibc might be other candidates for such a "basic level".) Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Inbound Product Mgmt T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE escribió:
There just seems to be a general FUD about change. So for example "zypper dup" was there, but in 11.1 we don't commit solid behind it,
what you mean.. ?
and now for 11.2 in the fate entry, noone seems to be really sure what work needs to be done to make it "just work" for most end users.
What has to be done is pretty clear, why you get that impression ?
There's a big danger, that openSUSE will look staler and staler,
I think we are far from stall...
and that we don't address the perceived quality issues
perceptions do not help, we need _evidence_, to debug you need a bug. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE escribió:
Let's just move to the well proven Debian model then,
It has been proven to be very useful to produce distributions in timely manner, aprox every 5 years and/or to provide new distributions with completely obsolete software to users. **grin** -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/8 Cristian Rodriguez
Rob OpenSuSE escribió:
Let's just move to the well proven Debian model then,
It has been proven to be very useful to produce distributions in timely manner, aprox every 5 years and/or to provide new distributions with completely obsolete software to users. **grin**
Lenny seems to be in good shape for release soon. etch was 2 years ago, and they made point releases. With rolling releases, having an up to date main release affects users less. They can install and then upgrade, on most systems. But lets not let facts get in the way of a good story. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/7 Cristian Rodriguez
Rob OpenSuSE escribió:
There just seems to be a general FUD about change. So for example "zypper dup" was there, but in 11.1 we don't commit solid behind it,
what you mean.. ?
The user base, don't think "zypper dup" is a supported upgrade method from 11.0 to 11.1, nor and there is a fate entry on supporting a "Debian like dist-upgradee".
and now for 11.2 in the fate entry, noone seems to be really sure what work needs to be done to make it "just work" for most end users.
What has to be done is pretty clear, why you get that impression ?
The fate entry on the subject.
There's a big danger, that openSUSE will look staler and staler,
I think we are far from stall...
After 2 intervening Ubuntu & Fedora releases 11.1 will look stale. The rough edges lead to unfavourable threads on forum and mixed reviews, and those show in Google search for a very long time. The KDE 4.1 with backports for 11.1 was nice, but that work seems to have very short shelf-life, given the timing of KDE 4.2. The thread proposes a way to make that less of an issue, and also planning to re-issue ISO's would hopefully help those who found 11.1 wouldn't boot on their machines. So far the improvement to Factory updates, seems to be the step that might lead to more testing earlier. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE escribió:
2009/2/7 Cristian Rodriguez
: Rob OpenSuSE escribió:
There just seems to be a general FUD about change. So for example "zypper dup" was there, but in 11.1 we don't commit solid behind it, what you mean.. ?
The user base, don't think "zypper dup" is a supported upgrade method from 11.0 to 11.1, nor and there is a fate entry on supporting a "Debian like dist-upgradee".
It can be supported, but when using a limited set of known repositories, IMNSHO.
The fate entry on the subject.
FATE cannot contain everything that has to be done or cleaned up before this to work, you can write a book of the size of "Don Quixote" on the subject, for the user is just zypper dup, internally for developers is a great deal of work, you have to deal with among other things - API issues - ABI issues ( tricky as hell, hint hint) - Correct a huge set of packaging problems - track backward incompatible configuration changes, without destroying user's configuration - Debug and fix all the bugs introduced by this changes (and goto 1) So far, no one has done it right...;-)
There's a big danger, that openSUSE will look staler and staler, I think we are far from stall...
After 2 intervening Ubuntu & Fedora releases 11.1 will look stale.
why it will look stale ? we are already making a new product , it takes time and considerable effort !
The rough edges lead to unfavourable threads on forum and mixed reviews, and those show in Google search for a very long time.
so what ? you want a perfect OS ?.. Im sorry to bring you down to earth, there is no such thing and will most likely never be, people will always whine and complain anyway ..it is very easy to do so when you are not one doing the work...
and also planning to re-issue ISO's would hopefully help those who found 11.1 wouldn't boot on their machines.
So you want people to waste the already limited resources available to respin a release just due to "being unable to boot on certain specific machines" ?? Im sorry but that does not qualify as a good reason for me. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/8 Cristian Rodriguez
Rob OpenSuSE escribió:
2009/2/7 Cristian Rodriguez
:
The user base, don't think "zypper dup" is a supported upgrade method from 11.0 to 11.1, nor and there is a fate entry on supporting a "Debian like dist-upgradee".
It can be supported, but when using a limited set of known repositories, IMNSHO.
Sounds like a very good start.
The fate entry on the subject.
FATE cannot contain everything that has to be done or cleaned up before this to work, you can write a book of the size of "Don Quixote" on the subject, for the user is just zypper dup, internally for developers is a great deal of work, you have to deal with among other things
- API issues - ABI issues ( tricky as hell, hint hint) - Correct a huge set of packaging problems - track backward incompatible configuration changes, without destroying user's configuration - Debug and fix all the bugs introduced by this changes (and goto 1)
So far, no one has done it right...;-)
The Debian solution, which is generally praised, doesn't attempt to solve all of these things. They seem to have managed to make it work "well enough" rather than "bullet proof", and not guaranteed dist-upgrade (full-update) whilst running GUI for example. The "Debug & fix" point, is why it needs clear publicity and testing effort. People can plan test areas, copy their configurations across and try updating, if they know it is supported. If API & ABI issues are a problem, then statically linked tools that update files on disk from one consistent state to another, would seem to be a good solution. Disk formats could change to (like when RAID & LVM formats changed), but some documented non-live procedure, to upgrade deprecated features would likely solve it for most ppl.
After 2 intervening Ubuntu & Fedora releases 11.1 will look stale.
why it will look stale ? we are already making a new product , it takes time and considerable effort !
Simply because Fedora & Ubuntu will be re-freshed more often. For example 11.1 has KDE 4.1 + backports, which is not what real end users want, they actually want KDE 4.2 or 3.5.10 now, and 11.1 is still going to install a reviled KDE4 software version (I know that's unfair but it is the general perception). So the point of the thread was to discuss alternatives. It has been discussed (somewhat) before around Christmas time. Those making suggestions are looking for solutions : - perceived shortage of alpha & beta testers - perceived reliability & installation success - perceived drawback of tying openSUSE release to other projects - difficulty verifying bug fixes (they are 'done' but checking that, means upgrading to a release that may not be available till months later) Really the roughly 3 releases in 2 years, talked about is doing same thing as the other distro's just slower. As I have good memory of pain of installing 10.3, and time it took to stabilise on my machines (yes I was unlucky), I do not have faith that simply extending the time till next release, will really change anything. The move to make Factory updates more efficient, does seem like a step to improve the situation. The easier it is to get close to development, the greater number (in time) of useful tester and developer contributions.
so what ? you want a perfect OS ?.. Im sorry to bring you down to earth, there is no such thing and will most likely never be, people will always whine and complain anyway ..it is very easy to do so when you are not one doing the work...
Actually I agree, that does mean that it's wrong to look to improve the situation. As it stands, being an active openSUSE community member, testing the alpha's & beta's, is a fair amount of work, reported bugs don't necessarily get fixed, nor were work rounds published in release notes. When bugs are reported, sometimes it appears that the assigned engineers are under pressure to get them CLOSED or RESOLVED in some quick way, rather than really solved.
and also planning to re-issue ISO's would hopefully help those who found 11.1 wouldn't boot on their machines.
So you want people to waste the already limited resources available to respin a release just due to "being unable to boot on certain specific machines" ?? Im sorry but that does not qualify as a good reason for me.
11.1 failing to install on an 11.0 machine looks like a significant regression to me, and not a "waste" to resolve. If sorting that problem involves "waste of limited resources" then there's something very wrong in the release process. As it stands, it appears that the release mentality required for retail sales of box sets is entrenched. openSUSE users are not the types needing certification and QA approval processes. Those with good net connections, really want the best possible OS, more of the time, with different compromises on new feature / stability trade off. Those without decent net connections, need solid releases, not stuff that need lots of updates, or ones that don't boot. All the big community releases, not tied by policies of a commercial distributer, have gone for continuous update models, with periodic release of installation media. There's a reason for that, and is not because they didn't listen to end-user requirements, or were not dog fooding. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/7 Gerald Pfeifer
On Tue, 3 Feb 2009, Birger Kollstrand wrote:
The basic level would then be the operating system, and that would define the naming of the release. So the release of the openSUSE 11.2 is connected to a specific kernel.
As some of us tend to say, the kernel tends to be overrated. ;-)
Yes, it provides the name to Linux or GNU/Linux, if you will, but from a desktop user perspective, for example, I should hardly notice if the kernel changes whereas an update to Firefox, OpenOffice or the desktop environment of choice is much more noticably and possibly distracting.
You idea as such is interesting, though! I guess I'd just move what you call "basic level" a bit upwards and potentially give more leeway on the kernel side. (The toolchain and glibc might be other candidates for such a "basic level".)
Could you specify how you would see the base? This is an area that I have little experience in, but I do know fro other project (work related) that toolchains are often expensive to manage. Which parts of the system costs the most work to keep updated? The kernel, toolchain, DE's, applications. Could it be an idea that in 11.2 , in paralell with the standard release, there is a "rolling" repository an that repository contains backports of KDE, Gnome and applications. The applications should then first be available in the build service and tested there, then discussed and eventually accepted on the factory list for inclusion in the "rolling" repository? Then there would only be one repository to add for users that want the the latest? Birger -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/9 Birger Kollstrand
2009/2/7 Gerald Pfeifer
: On Tue, 3 Feb 2009, Birger Kollstrand wrote:
You idea as such is interesting, though! I guess I'd just move what you call "basic level" a bit upwards and potentially give more leeway on the kernel side. (The toolchain and glibc might be other candidates for such a "basic level".)
Could you specify how you would see the base? This is an area that I have little experience in, but I do know fro other project (work related) that toolchains are often expensive to manage.
Unless a different release model significantly increases those costs, is that question really relevant? For 11.2, we know that we will need kernel, glibc, gcc, binutils, bash, fileutils etc. Making the distribution, involves internal program developments, like YaST & zypper features, and intergrating the work of other projects. A benefit would also be if we can find things like kernel regressions now, in 2.6.29 before the kernel developer's have layered other changes dependant on alteration which caused the regression. Finding flaws sooner, and getting fixes integrated upstream, saves costs as it is easier to maintain than 'private' patches.
Which parts of the system costs the most work to keep updated? The kernel, toolchain, DE's, applications.
Could it be an idea that in 11.2 , in paralell with the standard release, there is a "rolling" repository an that repository contains backports of KDE, Gnome and applications. The applications should then first be available in the build service and tested there, then discussed and eventually accepted on the factory list for inclusion in the "rolling" repository?
You mean, say that all 11.2 application improvements should be runnable on the 11.1 core, to try to increase the testing pool? Any package using a new feaure, involving higher version kernel, library, Xorg etc etc would have to fail gracefully with lower version, if not then that feature would have to wait till 11.3 or 12.0 release. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/9 Rob OpenSuSE
2009/2/9 Birger Kollstrand
: 2009/2/7 Gerald Pfeifer
: On Tue, 3 Feb 2009, Birger Kollstrand wrote:
You idea as such is interesting, though! I guess I'd just move what you call "basic level" a bit upwards and potentially give more leeway on the kernel side. (The toolchain and glibc might be other candidates for such a "basic level".)
Could you specify how you would see the base? This is an area that I have little experience in, but I do know fro other project (work related) that toolchains are often expensive to manage.
Unless a different release model significantly increases those costs, is that question really relevant?
For 11.2, we know that we will need kernel, glibc, gcc, binutils, bash, fileutils etc. Making the distribution, involves internal program developments, like YaST & zypper features, and intergrating the work of other projects. A benefit would also be if we can find things like kernel regressions now, in 2.6.29 before the kernel developer's have layered other changes dependant on alteration which caused the regression. Finding flaws sooner, and getting fixes integrated upstream, saves costs as it is easier to maintain than 'private' patches.
Which parts of the system costs the most work to keep updated? The kernel, toolchain, DE's, applications.
Could it be an idea that in 11.2 , in paralell with the standard release, there is a "rolling" repository an that repository contains backports of KDE, Gnome and applications. The applications should then first be available in the build service and tested there, then discussed and eventually accepted on the factory list for inclusion in the "rolling" repository?
You mean, say that all 11.2 application improvements should be runnable on the 11.1 core, to try to increase the testing pool? Any package using a new feaure, involving higher version kernel, library, Xorg etc etc would have to fail gracefully with lower version, if not then that feature would have to wait till 11.3 or 12.0 release. Yes.
Birger -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Mon, 9 Feb 2009, Birger Kollstrand wrote:
Could you specify how you would see the base? This is an area that I have little experience in, but I do know fro other project (work related) that toolchains are often expensive to manage.
Which parts of the system costs the most work to keep updated? The kernel, toolchain, DE's, applications.
I was not thinking of cost, but the implications of updating. From that perspective, reving the kernel should be easier to do than the toolchain (including glibc). Nearly the entire distribution depends on the latter relatively directly. Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Inbound Product Mgmt T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/2/10 Gerald Pfeifer
On Mon, 9 Feb 2009, Birger Kollstrand wrote:
Could you specify how you would see the base? This is an area that I have little experience in, but I do know fro other project (work related) that toolchains are often expensive to manage.
Which parts of the system costs the most work to keep updated? The kernel, toolchain, DE's, applications.
I was not thinking of cost, but the implications of updating. From that perspective, reving the kernel should be easier to do than the toolchain (including glibc). Nearly the entire distribution depends on the latter relatively directly.
That is what I was thinking about cost. Cost of getting in to problems, using unreasonable amount of man hours etc. Would it be posible compile get a list of what SW has the highest risk of impacting the distro the most if changed? Birger -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (9)
-
Administrator
-
Andreas Jaeger
-
Birger Kollstrand
-
Clayton
-
Cornelius Schumacher
-
Cristian Rodriguez
-
Eric Springer
-
Gerald Pfeifer
-
Rob OpenSuSE