[kde-solaris] KDE 3.4.3 Patches and Upgrades

[Stefan Teleman]

On Sunday 16 April 2006 12:42, Derek Konigsberg wrote:
> That all sounds very disconcerting, as a project like KDE should be
> striving to have a clean and *portable* code base.  (Whenever I
> have to "beat code into submission" to make it compile on Solaris,
> half the time I'm running into issues that only exist due to gcc's
> lax-ness anyways.)
>
> As much as it might sound like an undesirable fork, I'd definitely
> be interested in having a Solaris compatable source tree that was
> kept in sync with the "we only care about Linux" tree.  (along with
> a source distribution that anyone could download/compile/package to
> their needs)
>
> I'd even volunteer to host a repository for such a project, if
> that'll make things easier.  (I have a Solaris-based co-lo server
> that I'm always looking for more things to do with.)

Thank you for the offer.

I am in the process of setting up a SVN repository for KDE Solaris 
with help from a KDE Solaris friend. It's not ready yet, mostly 
because i've been so busy fixing these bugs, and i wanted to create 
this repository with a more complete set of bug fixes, but now i 
should be able to spend more time on it.

Bring up the issue of code portability, and you will be instantly 
dealing with three troll topics:

1. "Solaris sucks"
2. "Sun Studio Is Buggy -- GCC Is Always Right"
3. "This code is portable on my box"

Needless to say, i am not really interested in participating in any of 
these three discussion topics. :-)

The fundamental problem i see with setting up these "Friends of KDE 
Solaris"  repositories is that they make everyone realize that they 
are a secondary alternative to the real approach. And at this point, 
everyone is right in asking the question "why is KDE not interested 
in at least keeping at least some control over these forks ?" I am 
not convinced that having several forks of KDE floating around the 
world is maintainable, or desirable, in the long-term.

In a theoretical world, there should not be a need for operating 
system specific forks. In the real world, anyone who has ever been 
involved in writing complex systems, required to work correctly on 
more than one flavor of UNIX, knows that this theoretical ideal is 
simply not possible. At this point, one is faced with two choices:

- keep everything in one trunk, and #ifdef every other 10 lines of 
code. if you want to see how maintainable that codebase can become, 
take a look at X.
- have one "main" trunk, and subordinate forks for specific UNIX 
flavors. this keeps trunk clean, keeps the subordinate forks cleaner 
as well, and does not pollute the main trunk with flavor-specific 
changes. and it keeps Solaris specific changes away from those who 
are allergic to Solaris. :-)

It is also equally true that Sun should have been, and should be, more 
involved in helping KDE Solaris. It *is* in their own interest to do 
so. Well, they aren't. They keep trying to push that JDS product. 
Sorry guys, that ain't flying. They've been at it for 5 years, and i 
still can't think of a single reason why anyone would ever consider 
using JDS. 

And this is *not* a GNOME jab. I have nothing against GNOME, and i'm 
not interested in getting involved in some stupid "GNOME vs. KDE" 
flamewar. Just take a look at any real distro of GNOME, then take a 
look at JDS, and then reach your own conclusions.

--Stefan

-- 
Stefan Teleman          'Nobody Expects the Spanish Inquisition'
steleman at nyc.rr.com                          -Monty Python