On 09/01/2014 02:54 PM, Luca Beltrame wrote:
#include lines, etc to new ones, Frameworks involve creativity. thought. That's cool. Applications are boooooring.
I don't see the point of sarcasm. The idea is to increase use of KDE software in the larger Qt ecosystem. I hardly think a modularization is a bad idea. Also this means that applications can have more fine-grained dependencies.
I'm sorry you see that as sarcasm. It isn't. I've been a developer and manager of development teams and a packager and also done the documentation side, and I know there's fun, creative stuff and boring tedious stuff, The latter has to be done. Sometimes you can determine patterns and automate it, sometimes not. I'm all in favour of better, more fine grained dependencies. Too much of what we have in the repositories at the moment have dependencies that are an artefact of the way things have been packaged rather than a real dependency. I'm not put out by making the zypper guts do more work :-)
BTDT. Quit a job rather than spend ho-hum days checking all the old apps worked with the new release.
KF5 is done to minimize API and ABI (binary compatibility) breakage, but it is *not guaranteed*. Just like Qt 5 is not compatible with Qt 4. So, at least by the way you wrote this, it is not possible by design.
Since that doesn't really relate to what I was thinking about when I wrote that or any permutation of my intent, I think it might help if you expanded on your explanation. You seem to be implying that at the moment there *is* breakage - whatever that is. Are you saying that, like with Qt4/5, KDE4/5 has "breakage"? Does that mean that apps we have now won't work with KF5? Which gets back to the point I was trying to make. This leads to .... migrating to 5 means the apps we used with 4 don't work until someone has done the (boring) step-and-repeat of whatever it takes to recompile or possible rewrite them to use Qt5 and run under KF5. That seems to logic to me based on what you are saying: > They need to be ported because API and ABI changed
Are they fully compatible? Has anyone - ho-hum - checked? If so, why do they need to be ported?
They need to be ported because API and ABI changed, stuff has been deprecated, etc. Also, Qt includes new things contributed by KDE, which means that some old kdelibs specific bits need to be removed. Again: Qt5 is binary incompatible with Qt4.
So, until they are all converted, (or at least the subset I use) I'm not even going to be trying. And the subset of the apps I use are not going to be the same as the next guy or the next. How are you going to prioritise this?
Sounds like its going to be confusing for a lot of people, most notably the poor end users like me.
Actually the bulk of the work stays on the shoulder of the developers (coordinating this is not trivial) and packagers (track deps, repos, etc). At least in openSUSE we'll do our best to ensure the change is transparent to the end users.
FWIW, rightly or wrongly, the KDE3/4 transition recognized that that the developers were not alone in this, that the end users played a very important part. Perhaps it was mismanaged, then, and perhaps that mismanagement is what you are trying to avoid now, but do avoid hubris. The KDE3/4 recognized the important part that end users play in the development of FOSS, their reports of use, usability, 'edge cases', and of course bugs. The handling of "activities" is a good example of that feedback. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org