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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
