Thank you to all who have replied. I lost so much faith in the upgrade installation from 10,1-10,2 because there were so many issues. I did start bug reporting some of those issues in the beginning, however due to the volume of issues with the whole process, the Evolution/KDE password issue I lost a lot of faith in the whole QA system.
Many thanks for those who are testing the upgrade cycle. Ill let you know how I get along with the RC of 10,3 upgrading a 10,1 install I still have one PC running. Scott G.T.Smith wrote: > 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...) > > > >
smime.p7s
Description: S/MIME Cryptographic Signature
