On Wednesday, 22 March 2017 18:18:20 CET Ludwig Nussel wrote:
Wolfgang Rosenauer wrote:
Am 22.03.2017 um 09:59 schrieb Ludwig Nussel:
Wolfgang Rosenauer wrote:
Am 20.03.2017 um 17:18 schrieb Marcus Meissner:
> Note that the openSUSE Leap 42 class of distributions is designed to
> be easily
> upgradable within minor versions, so Leap 42.1 to Leap 42.2 update
> be easy and seemless.
and if they are not?
That list does not look too bad but it's just for the "Upgrade"
component. There may be others.
What concerns me is that almost all are NEW.
At least one of them made me stop ugprading my remaining 42.1 systems at
least temporarily in the hope that there might be patches coming up.
So the question is how to deal with unresponsive package maintainers?
I'm not saying I have a solution for that. I mean it hurts Leap's
reputation and given that some affected components are rather critical
especially in server environments where Leap was supposed to replace
Evergreen (at least in my mind) this is a problem.
For example I'm pretty sure that SLE has openldap as well. How and who
would deal with that component in SLE and why is there a disconnect
between SLE and Leap there? Or is there none and SLE is broken the same
way? (I doubt that.)
Unfortunately in this specific case I don't have records as to why
we accepted the deviation :-( Nowadays the leaper bot would leave a
comment and warn already.
IMHO we as a project should try everything to
avoid that or mitigate
such situations. Unresponsive maintainers can always happen
unfortunately for many reasons.
Probably there are or should be a few key areas where we introduce a
fallback to drive things forward?
Reaching out to this list is one way. I've also pinged the SLE
maintainer to take a look.
Also, the upgrade tests in openQA need more attention. So far we
only test updates of basically default installations but not how
extra services behave.
Agreed. More community effort would be appreciated to extend the test coverage
with openQA tests on that matter. I can think of the following first steps:
* compare to openSUSE Tumbleweed regarding the coverage of scenarios, maybe we
can simply enable some more for Leap after someone proved they work
* extend the update tests to also check extra modules, like with the "extra
tests" on the upgraded hard disk images
* install and configure more different stuff in the base images that are then
upgraded to a newer version
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org