On Wed, 2012-08-08 at 07:35 -0400, Adam Tauno Williams wrote: > On Wed, 2012-08-08 at 10:05 +0100, Pete Biggs wrote: > > On Tue, 2012-08-07 at 13:24 -0600, Brian A Anderson wrote: > > > <Begin editorial mode> > > > The key things that I learned here are; > > > 1. the two different versions of Evolution had two different mailbox > > > styles. > > > 2. The two versions of Evolution were not compatible. > > > 3. the evolution of Evolution had abandoned those with older systems. > > > Cynical but apparently true. > > I don't think that's entirely true or fair. > > Did you give Evolution a chance to upgrade your data structure? > > Yes, the user posted about their success/failure using > backup-and-restore to this list. backup-and-restore is pretty well > known to not work across multiple major releases. >
Again my situation was a bit different as I said in my first paragraph. I was really doing a merge more than a restoration. So some of the suggestions were never going to "really" work completely. > > i.e. did you start Evolution > > with the old files in their original place rather than trying to do it > > through the backup files? > > Yes; or at least I believe the poster said that. > > > > Backwards compatibility is very important. > > To a point; but the user is jumping across many major releases. It is > unreasonable to expect it to work well, IMNSHO. This is like jumping > from Microsoft Access 97 to Microsoft Access 2010; it 'works', but a > fair amount of remediation is required. Oh, gawd.. now I'm having > flash-backs... > First of all the version of a piece of software is merely a way of categorizing a set of procedures it should have no further impact. Consider this; Take for example how we consider travelling. We are all canonical travellers, we are passengers on planes, we have luggage. But none of us need to know what kind of plane, how it works etc. The way in which Ohare, JFK, Logan, SFO, LAX etc all work are slightly different. We don't need to care about those issues. Now look at evolutions data store. Each canonical message under 2.24.5 and 3.4.3 are stored differently. Yet they arrived into their versions of evolution using the same mechanisms. Why should the backup not maintain a canonical form of all the aspects of a mail system vs backing up on the way in which the data is stored. A canonical form would have forced all versions to be able to backup and restore with full backwards and forwards compatibility. The canonical form could evolve with versioning of data forms as they get more complex and programs evolve. So How many users really want to be slaves to version creeping and version hopping? > Evolution 2.24 is *old* [circa 2008]. Especially in Evolution time > where things seems to sit stagnant at the 2.2x level for a long time and > then pulsed forward through 2.3x and now on to the [vastly improved] 3.2 > and 3.4 era. > > But the user did publish notes, so kudos. Might be useful to someone > else later on. > > > Evolution is probably one of the best applications I know for upgrading > > internal storage formats - it is quick, unfussy and accurate. > > Yep. > > > > Some versions may not offer a real reason to migrate. > > > I for one don't want to become a slave to updates like Windows users > > > are a slave to updates. > > But you *must* install updates for any operating system - they fix bugs > > and, most importantly, they fix security holes. It just simply should > > not be optional to install updates. > > The user certainly doesn't need to rush to update; too many LINUX users > are addicted to the next-greatest-patch which is an attitude that > seriously impedes real world productivity [hey, let me update first > thing Monday morning and break my desktop!]. 'Immediate update' also > provides no pragmatic upside [let's be honest - *most* security fixes > are pretty obscure and only effect boxes using particular > applications/services in a particular configuration]. Name me two security fixes to Linux that fixed publically seen and experienced problems. Not just those that some security geek says are important and are possible. But happened. By the way I used to work in network security. > > I apply updates once a month; and I typically upgrade my distro a full > month after a release [plus a month worth of updates]. This has > provided me with a very smooth ride. I try to recommend this policy, > but immediately after I say this most users are subscribing to a factory > repository and doing a "zypper up"... sigh. :) > I am glad that you have had a good luck with a monthly update. I have in several years attempted only two updates. AND BOTH FAILED TO COMPLETE! The last one left me with a dead system. > > In that case, with all due respect, why are you using Fedora! If you want > > stability, then use a RHEL clone such as CentOS or ScientificLinux - > > they will guarantee support for about 5 years after EoL of a particular > > version - but you still have to install updates. > > Agree. If long-term is what the user is looking for then Fedora is a > mismatched choice. Fedora *is* the distro of latest-and-greatest [which > is not a criticism, but maybe that is not where the user wants to be]. Not really relavent. As the concept of having a stable system to use in an office setting with seldom if any updates is not a risk even in your latest/greatest observation. The greatest risk once a stable system has been found and evolved to, is the introduction of updates. I started using Linux vs Windows as an attempt to explore alternative environments for an occasional developer (read as semi-retired). I found that once stable it was good. There were/are some shortcomings but it has worked for me. My Linux laptop is up for more than 30 days at a time without restarting. My longest stint with any Windows was about 3 days and then that laptop almost rebooted itself. I do have a real problem with doing updates for the sake of updates. I don't go and buy the latest version of any technology because it came out. Like the Tommy Lee in "Men in Black", "now I guess I have to buy the Beatles White Album again". Why can't a stable system be put together occasionally that can be moved to that has the ability to migrate data forms. Remember the canonical form. If it were used migration would never be a problem. > _______________________________________________ > evolution-list mailing list > [email protected] > To change your list options or unsubscribe, visit ... > https://mail.gnome.org/mailman/listinfo/evolution-list _______________________________________________ evolution-list mailing list [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
