Tell who did you PAY to include Akonadi?

[Duncan]

Kevin Krammer posted on Sat, 31 Mar 2012 13:11:21 +0200 as excerpted:
> On Saturday, 2012-03-31, Duncan wrote:

>> >> Kevin Krammer posted on Sat, 31 Mar 2012:
>> >> > http://www.betterinbox.com/

> Btw, I believe that ksmtp is fully their work, so their contributions
> are more than just "a couple of changes here and there"!

=:^)

> One thing I forgot to write previously is that since they seem to use
> IMAP and SMTP, the client will likely also work with other mail service
> providers. Being a company they probably want their official
> documentation to only list ones they have tested with but not meaning
> that it doesn't work with others.

Makes sense.  But if it doesn't have POP3, it won't work for me, 
currently.  But that doesn't take away from their contributions or that 
it might work for others, or for me later.

>> I do like the idea as extended into (what I've read of) kde frameworks.
>>  Between the greater kde modularization and the migration of some
>> current kdelibs functionality into qt5 (which is from what I read
>> itself tilting toward more modularization)
> 
> Qt4 is already quite modular, i.e. its libraries usually don't depend on
> each other (each one depending usually just in QtCore) and application
> developers can easily decide which ones to explicitly use.
> 
> My understanding is that on top of that Qt5 modularization is mainly
> changing how Qt is built, e.g. specialized libraries having their own
> repositories and not needing to be switched on or off when building Qt.

Of course being a gentoo user, that's the perspective I tend to see, and 
gentoo is script-automated from-source package builds, so from here, "how 
Qt is built" really IS end-user detail. =:^)

FWIW, gentoo already has qt-4 broken up into its split modules, and has 
qt-based app dependencies set accordingly, but just as with kde's 
formerly huge monolithic tarballs that are now being gradually split out, 
having them actually shipped split-out from upstream, and having the 
split modules dependencies specified explicitly as a result, is going to 
reduce the work load (and bug-load when it turns out wrong) for distros 
like gentoo that already split them up, TREMENDOUSLY.

As big as the kde project is and as many packages as it has, kde and its 
underlying qt have been MAJOR operations at the distro level, and while 
the split won't much affect the number of individual packages for distros 
that were already splitting them, lifting that dependency-tracking 
workload from the distros back to upstream (with I'm sure an occasional 
distro fixup, as happens with every package) should be quite the 
standardization and stability boon, lessening the distro work load and 
end-user seen dependency bugs dramatically for those who already have it 
split, while equally dramatically increasing flexibility for those are 
still getting the monolithic packages.

So as you can see I'm very optimistic about the results of this at all 
levels, qt and kde upstreams, distros, and end-users. =:^)

> I am not sure it will make a difference for users since dependencies are
> handled automatically already anyway, but my guess is that the added
> flexibility will incur some extra cost for developers and especially
> packagers.

The difference for users will be in flexibility if they're currently 
using monolithic, and in number of bugs if their distros/packagers are 
already splitting it up (as is gentoo), since much of the work will be 
transferred to upstream, where it'll be common to all packagers instead 
of each one having to develop their own solutions.

>> If the module releases are desynchronized as well, as I've read is
>> being discussed, letting the modules evolve at their own rate, it could
>> be a good thing.
> 
> True, but I don't think this will be employed anytime soon, at least not
> for the traditional modules. Faster moving products like Plasma on the
> other hand might switch to separately released libraries sooner.

Makes sense.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.