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

List:       kde-release-team
Subject:    Re: [PATCH] Making Soprano optional (again) in kdelibs
From:       Mike Arthur <mike () mikearthur ! co ! uk>
Date:       2009-12-30 0:09:21
Message-ID: E1F42BB8-D7F7-4800-A560-5AB9F9EF49A0 () mikearthur ! co ! uk
[Download RAW message or body]


On 29 Dec 2009, at 23:43, Jorge Manuel B. S. Vicetto wrote:

> If "common sense" won't cut it, do I need to start a vote, forum thread
> or something else asking KDE users (I can do it for Gentoo alone) if
> they are worried/upset about this? Should I ask how many "former KDE
> users" stopped using it because of the MySQL dep?
> If you want, I can point you all to the user rants in Gentoo bugs about
> MySQL dependency for KDE as a whole and amarok as one particular KDE app.
> Why is it so hard to understand that KDE is getting more and more bloat?
> By the way, no other distributions / packagers have issues with the KDE
> dependencies?

Perhaps you could instead try to defend the decisions of the KDE developers and read \
the various FAQs stating why a relational database is being used and forward this to \
your users who are complaining.

http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_sqlite.3F

This would be a good start to forward people to.

> As Maciej hinted, you're opening the door for another group of KDE devs
> later call for precedent to add hard deps on sqlite, postgres or
> whatever is their favourite DB. Requiring full blown relational
> databases for a DE is probably a good sign that someone is going in the
> wrong direction. Again, I can point you to comments by users in Gentoo
> bugs complaining about this - it's not just "my individual opinion".

Would you care to elaborate why you know better about the requirements of the PIM \
applications than the KDEPIM developers? As I stated earlier, feel free to write the \
code to match the performance and functionality without a database.

The idea that there will be another bunch of databases required doesn't really apply \
here as the two applications you've cited both use MySQL, making it more and more \
likely that any other KDE applications will start to use MySQL too.

Another way of looking at it which you perhaps haven't considered is that \
dependencies are a good things as they are shared, stable code that we don't have to \
maintain. This means KDE can get better rather than worrying about how to store \
information on disk. In KDEPIM, for instance, moving to Akonadi and using a database \
has allowed a lot of code to be removed.

Your concerns are known already, they were raised loudly when MySQL was first \
proposed for Akonadi and for Amarok. However, unless you have an actual technical \
solution to the problem that many of the KDE developers have tried to solve then \
                raising these issues again is just demotivating.
--
Cheers,
Mike Arthur
http://mikearthur.co.uk

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


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