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 should 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.
https://bugzilla.opensuse.org/buglist.cgi?classification=openSUSE&compon ent=Upgrade%20Problems&list_id=6284328&product=openSUSE%20Distribution&q uery_format=advanced&resolution=---&version=Leap%2042.2
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?
Probably :-( 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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org