Le mercredi 27 mai 2015 à 12:58 +0200, Stanislav Baiduzhyi a écrit :
It is sad to see that interesting thread was stolen by some absolutely irrelevan discussion about numbers. I still have some qeustions about how will it work exactly, hopefully Richard or someone else from the merging initiative will be able to answer it:
1. In context of SLE, what does SP1 means? Does it include only backports of fixes, or does it include version bump as well? Which effectively means, will the core of openSUSE N+0.1 be version updated with the release of SLE SP N+1 or will it stay the same? Good example will be higher Qt5 version requirement for plasma5.
With my SLE Desktop release manager hat: - usually during a service pack, we try to only backport fixes but for some particular features request, we might do a version bump, usually because the feature we need can't be backported easily or the resulting package would be too difficult to maintain - during SLE12, for service pack, we might be a bit more flexible regarding version bump for some components (compared to SLE11) - so far, for SP1, there is no plan for big version bump (mostly because SP1 will try to stabilize even further SLE12 GA). Regarding Qt5, we don't have plan to do a major version bump for SP1 (because we don't have a need for it, feature wise) but doing a version bump in SP2 is kind of expected. oh, and please, don't take those comments as "everything is set in stone" ;)
2. How the important updates of core packages will be handled? Good example is recent release of GCC 5, it exposed lots of issues in different pieces of software, but lots of people would like to establish it for some reason. I would assume that the change will not go to SP in SLE, maybe only to next major version. Does it mean the same for openSUSE, or will openSUSE be used as a playground/nightly for SLE to get rid of all possible transition issues before the release of SLE?
For gcc, this is different, because this will be a "toolchain" module for SLE customers (think of it as some additional repository) which will be in place and will update gcc stack on yearly basis, independent of the service pack. This is to allow customers who need a more recent gcc to get one, without replacing the "system" gcc. SLE people are not recompiling and shipping the SLE codebase with the new gcc major version, because it might add new bugs and I'm not sure it would be a good idea to do this on openSUSE, since openSUSE would loose part of the stability gained by reusing SLE codebase at its core. For smoothing transitions caused by a new gcc, I think TW is more appropriate.
3. Will it be possible to have different repos for core of the system (not sure if that's what Ring 0 and Ring 1 stands for) and other pieces of the system? With some previous releases of openSUSE adding updated KDE repositories allowed the unholy mix of official/updated versions if there were any package name changes, which became obvious only much later. Would be great to have built-in defence against such cases by making it just separate repository.
I guess it will be a matter of the various projects maintainers, not really "openSUSE:42" itself.. -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org