[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Commit policy for kdepim HEAD
From:       "Carsten Burghardt" <burghardt () kde ! org>
Date:       2004-08-19 10:43:45
Message-ID: 3795.149.235.78.213.1092912225.squirrel () h1979 ! serverkompetenz ! net
[Download RAW message or body]

<snip>
>> But what about the rest of the world like
>> other distributions?
>
> Some distributors already take changes from HEAD and distribute them.
> I guess they would like more frequent kdepim releases, it depends on
> the distributor.
>
> I benefit from the same thing any distributor does. A long lived kde
> packaging format that doesn't change often benefits me. So as I said
> I'm against splitting up kdepim and releasing individual apps
> separately.
>
> Also like any kdepim developer I benefit from being able to cvs update
> and compile kdepim without having to do update kdelibs (and kdebase)
> to get things to compile. By the same logic having the imap slave in
> kdepim is a good thing. If people who make changes in kdepim that
> require unreleased features in CVS HEAD kdelibs #ifdef those changes,
> then they are being kind and considerate and I appreciate that.

I do agree that it's very nice if you don't have to update kdelibs/base
when you recompile kdepim.
But these ifdefs are pretty hard to maintain. Just imagine what would
happen if the new kdepim has to be compatible to kdelibs 3.2, 3.3 and
HEAD.Aparently there are always features from kdelibs that would be needed
in kdepim and the result was to copy classes to kdepim. And that is a
PITA.

Carsten
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]