The upgrade process from RC 10.1-10.2 was abysmal. The upgrade does NOT take much notice of all the applications that currently exist and upgrade them all. For example. I have a KDE desktop with Kmail and associated files deleted and at the time Evolution installed with the addition of Monitor class applications, Wireshark and a few backup tools. When I upgraded I got a KDE desktop, New fonts, Kmail, NO Evolution,NO Monitor class tools, Some backup tools went missing a ZEN updater applet and in the desktop applet menu the open suse updater which would only stay in the system tray for 1 session and when ZEN was deleted it remained and worked. In other words it should read the total applications database and upgrade that database and install if required dependant files - Clearly 10.1-10.2 did not do this...If is saw a KDE desktop it performed a KDE pattern groups update and to hell with any other application outside the pattern group. sorry very passionate here Scott chika@cs.its.ac.id wrote:

do you mean that in your case it's better to get new installation than upgrade method?

if i look the development from 10.2 to 10.3 alpha i didn't see significant ... may be only kernel(if any) .. so the upgrade is better for me than took longer time to download n install it form beginning ==> give me the clues if im wrong about this

cheers,

tambun

...

For those people out there testing the next version of open suse 10,3 - could some great degree of testing involve testing the Product in a upgrade situation rather than a New installation. After I upgraded 10,1 to 10,2 RC I came across more bugs to the extent that the upgrade ability could only be rated as beta. I begin reporting upgrade bugs, however due to the enormity and frequent comment by suse.de (Then you should not buy new software). I was not prepared to waste more of my time. I always buy boxed software and my only plea for Alpha 10,3 that a great deal of testing is done via an upgrade (not clean) installation I have been testing software (given most of my earlier life's experience was with large Main Frame installations), and latter PC operating systems. The upgrade path for all New software application development is always the most difficult to achieve. As an active tester of RC software I need to gain some personal confidence that upgrade-ability has been tested by a few more dedicated other

Kind Regards and Good Morning 06:30 GMT+10 Scott

Alexey Eremenko wrote:

The problem with your ask is that we are, as a community, are volunteers, and as such we prefer to focus on features we use ourselves.

That is if some tester prefers new install and KDE, he will mostly (or only) test KDE with fresh install, not matter how buggy other parts of the distro are.

For one part I never do "upgrade" install, as I prefer fresh in all cases. For me it is OK to drop that feature. If feature X goes unmaintained and untested for long time (as 1 year or so) it gets dropped from the distro eventually.

This basically means, that if feature X is important to you in a community distro, you should test it yourself. The recommended time to enter testing is BETA1 release.

On some occasions one does not have much of choice but to upgrade, and it tends to be a bit quicker than building a new installation from either backup or scratch. At the moment there are no data or configuration migration tools for SuSE that I am aware of. Backup can be used as a basis for restoring, but on multi-user systems this can get messy (especially if the base UID is changed as it was a few versions ago). A new distribution will include newer versions of application packages that will have particular upgrade issues related to that package. Most will flag any problems, and detail known issues. To have SuSE testers duplicate the activity of the the package testers and developers seems to be a duplication of effort, and given we are talking several hundred applications that is a lot of duplication. What really is needed are migration/upgrade notes compiler so that people can be informed of what work will be needed on which packages, before they embark on the upgrade. What could probably be useful is a web page detailing the packages versions installed linking into the relevant packages information on update requirements on the developers sites, and any specifically SuSE related issues. What would be even more useful is If a package update link database was setup, it would be possible to generate update documentation tailored for a particular installation. (The database bit is hard.... the document generator relatively trivial...) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Thank you for your realistic upgrade scenario in a nutshell. From my perspective opensuse is used in a production environment. Yes I know I should be purchasing SLED, however the direction I have chosen for my small company is to expose everyone to using the O/S and applications before we just about renounce commitment to M$. Much has gone well with opensuse and I will commit funds to a Suse Network sometime next year. Being a research and non-profit organisation I have to take a great deal of care the money I can justify to enjoy computer applications to make life easy and profitable. In that sense all the data is not replaceable. I also have no choice but to upgrade each workstation and like other real world examples others users are also committed to upgrade installations. It is not a difficult concept that the major applications and data should still be there after the process and one which is realistic. The community uses opensuse for many reasons. Some of us like myself, are dependant on the package for our existence and I trust I am not alone, however I may be a little bit slow to move to SLED/S. Fortunately I have learnt how to retain all data we produce and duplicate it, in the case I have to do a new install and re-instate the data after. Its amazing the different type of users, using opensuse for totally different and sometimes opposing view points. For many the package is simply a tool of getting from A to B in a automated fashion and in a computerised environment. For others, the package is their total source of amusement and they just want to play with anything; and if they stuff up they format and re-install. There are other corporate testers - just interested enough in the package to integrate the O/S and main stream apps to perform token, but still critical aspects of their total automation. Then there are the O/S and command prompt poke it and see game. And some where a PC defines their life. Such is the spectrum we all see here in the list and with everyone's unique take on their expectations of the package; delivers/modifies/changes the evolution of Suse Linux (open or otherwise) into a product that corporate and missions critical consumers are now taking a big look at. There are Hardware vendors taking a big look at Suse Linux, and in each of our ways we have helped this along - well that's the hope I hold on too. G.T.Smith wrote:

On some occasions one does not have much of choice but to upgrade, and it tends to be a bit quicker than building a new installation from either backup or scratch.

At the moment there are no data or configuration migration tools for SuSE that I am aware of. Backup can be used as a basis for restoring, but on multi-user systems this can get messy (especially if the base UID is changed as it was a few versions ago).

A new distribution will include newer versions of application packages that will have particular upgrade issues related to that package. Most will flag any problems, and detail known issues. To have SuSE testers duplicate the activity of the the package testers and developers seems to be a duplication of effort, and given we are talking several hundred applications that is a lot of duplication.

What really is needed are migration/upgrade notes compiler so that people can be informed of what work will be needed on which packages, before they embark on the upgrade. What could probably be useful is a web page detailing the packages versions installed linking into the relevant packages information on update requirements on the developers sites, and any specifically SuSE related issues. What would be even more useful is If a package update link database was setup, it would be possible to generate update documentation tailored for a particular installation. (The database bit is hard.... the document generator relatively trivial...)