Re: [Evolution] DST
- From: Paul Smith <paul paulandlesley org>
- To: Peter Van Lone <petervl gmail com>
- Cc: evolution-list gnome org
- Subject: Re: [Evolution] DST
- Date: Mon, 26 Mar 2007 09:43:27 -0400
On Mon, 2007-03-26 at 08:15 -0500, Peter Van Lone wrote:
On 3/26/07, Matthew Barnes <mbarnes redhat com> wrote:
Exceptions to the rule have been made, however, and there is some talk
of whether it would make sense to upgrade the major desktop applications
(Firefox, OpenOffice, and Evolution) at some point before RHEL 6. I'm
in favor of that; it would make my job easier. But nothing official has
been decided.
Well, for things like the DST problem it's not really necessary to
upgrade to a newer version of Evo, much less Gnome. The fix is not
difficult at all and could trivially be backported to older releases by
the various distro vendors. Heck, I fixed my Ubuntu install by hand
with a text editor.
It's very uncommon, actually, in the open source world for the
maintainers of software to release older versions of their code with bug
fixes provided. It is not at all surprising to me that the Evolution
developers are not putting out patched versions of Evo 2.4, 2.6, etc.
with the DST bug fixed. That's not just how free software works.
It's the job of the distro to do that work of backporting important
bugfixes and/or releasing newer versions of software to fix issues with
their distros. That's what you pay them for (assuming you pay them).
If you don't like the job they do, then you should find another distro
with a better track record.
I realize that people get a bit confused by the fact that many of the
Evolution developers work for Novell, which also produces its own
distro, and they conflate the work that needs to be done by the distro
and the work that needs to be done by the upstream developers. However,
it's quite possible (I don't know anything about the inner workings of
Novell so I'm not sure) that the people who develop Evo have absolutely
no insight into or say over what gets updated in released versions of
SLED. That would not surprise me in the slightest.
This mailing list is intended for users and developers of Evolution. If
you have a problem with your distro not providing timely
patches/upgrades to Evo, then this is NOT the right place to talk about
it (even if your distro is from Novell). You need to find a support
forum specifically for your distro, and complain there. Alternatively,
find a new distro that DOES provide the support you need.
Of course, we're happy to help resolve the problems you're having, but
we can do nothing about whether your distribution provides you with the
support you need.
I guess then, from my perspective (being a reseller/integrator trying
to develop linux desktop offerings for customers) I would certainly
vote to enable upgrade of "the major desktop applications" within
versions. SUSE supports SLED for 5 years.
It's not necessary to upgrade: important fixes and often be backported.
Debian, for example, has a long history of doing this. They have a
policy of NEVER upgrading to any newer version; they always backport
fixes. Of course there are rare exceptions that prove the rule, but
they are very successful with this and as you know, Debian has a very
slow release cycle.
However, again, this is something you need to take up with your distro
support folks.
I do wish evo was a little less dependant on gnome parts ...
This is unquestionably a double-edged sword. As I've written here
before, the entire reason that we even HAVE this DST problem in Evo is
that someone made the extremely poor decision, back in the day, to have
Evolution use its own internal format and database for daylight savings
time/timezone information rather than using the system's timezone
database. So, when all the distros released patches to update their
system timezone database with the proper information, that fixed all the
applications on your system EXCEPT Evolution. If they had only been a
little MORE dependent on the underlying system, in this case, the entire
problem would have been avoided.
The reality is that duplication of code is rarely the best answer in the
long run, regardless of how much it simplify things in the short run.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]