27 May
2015
27 May
'15
11:59
Frederic,
Thanx for the responses. Some follow-up questions below...
On Wednesday 27 May 2015 13:17:05 Frederic Crozat wrote:
> Le mercredi 27 mai 2015 à 12:58 +0200, Stanislav Baiduzhyi a écrit :
> > 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" ;)
That makes sense. But that means that the gap between SLE and openSUSE will
increase with number of SPs, increasing efforts for both parties, or is there
some plan to keep sharing the effort in preparation for next major SLE
release?
> > 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.
Looking at packaging and buildservice mailing lists, looks like there are some
issues when people are trying to use non-default gcc version for their
projects. How do you think, will that be resolved, or will newer version of
(for example) gcc be provided only for developers working on SLE/openSUSE and
not for OBS-built packages?
> > 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..
Ah, ok, this distinction is not yet clear to me.
--
Regards,
Stas
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-factory+owner@opensuse.org