Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3

[Pete Biggs <pete biggs org uk>]

> 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.

And you were doing a merge because you started using Evolution before
letting Evolution see your original data - that's really what I was
getting at.  Yes, the upgrade procedure from very old versions of the
backup file is less than optimal, but I don't think that is sufficient
grounds to say that Evo "abandoned those with older systems", especially
when you didn't really give it a chance to update in-situ files.

> 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.

Yes, the backup/restore process is fairly naive - it is basically dump
the config data from gconf (or dconf) and then tar it up with the data
files - the restore process is the reverse, untar the data and dumped
configuration, then merge the config into gconf.  The problem with using
such an old backup file is that the format of all the components
(configuration and data store) has changed, as well as the location of
those files.  It was never meant to be used when upgrading systems, it
was meant to be used to backup and restore data to the same version.

> The canonical form could evolve with versioning of data forms as they
> get more complex and programs evolve.

Yes, that would be a good ideal - I'm sure the developers would welcome
any help you can give them in re-writing the backup and upgrade code.
The issue really is how much effort should be put in to dealing with
something that is relatively rarely used - the developers team is small
and they are hard pressed.  If you think this is an area where Evolution
needs to be improved though, then file a bug on it, and if it is given
sufficient support, then no doubt it will be looked in to.

> So How many users really want to be slaves to version creeping and
> version hopping?

Users don't - that's why I put them on systems that don't have short
lifetimes.

> > 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.

Metasploit (a framework for "ethical" intrusion and penetration testing)
has over 650 usable, live remote exploits for Linux.  There are then a
whole load of privilege escalation exploits to gain root.  Not all the
exploits work, mainly because systems have been updated and patched so
they don't work.  But they do work on systems that aren't patched.

Before I took control of all the Linux boxes where I work, I was having
to deal with intrusions about once a week - virtually all of them on
unpatched systems; now I enforce updates and have locked the machines
down, I get virtually no intrusions.

These are real world, real intrusions, real data loss, that happened.

> > 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!

Updates or upgrades?  I have about 200 Linux systems, they automatically
update from repositories (strictly controlled repositories!) and I've
never had an update that left a system in an unusable state.

Upgrades are different matter.  You can't do major version upgrades on
RHEL/CentOS systems, it is always a wipe and re-install.

> > > 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.  

It is very relevant: you won't get a stable system if you don't update
Fedora - it is designed to be a cutting edge environment, the programs
have bugs in them - the bugs get fixed, but if you don't update, you
will never get those fixes. If you want stability, don't use Fedora or
Ubuntu.

> 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 have Linux systems with 2-3 year uptimes.  But I also have Windows
systems with long uptimes because their environment is also strictly
controlled - it's very easy to bash MS systems, but most of the problems
are caused by non-MS software.

> I do have a real problem with doing updates for the sake of updates.

To use a car analogy, if your car had a critical safety recall, would
you get it done?  Even if there was nothing evidently wrong with your
car now?

P.