[kde-community] Why were there no talks about Ubuntu Mobile at Akademy?

[Aaron J. Seigo]

On Wednesday, August 21, 2013 09:14:58 Michael Zanetti wrote:
> - Not all areas can be shared.

This is true. So let’s focus on the many things that can be instead of 
focusing on what can’t be done :)

> I for one work on Unity8, which just works
> and looks so different in every way than plasma does. We don't need
> Plasmoid containers, you don't need search scopes. 

How do you know we don’t need search scopes?

The functional similarity between “search scopes” and Plasma::AbstractRunner 
is pretty stunning, actually.

> - Once there is something which might make sense to be shared, it requires
> the exact people working on it having interest in collaborating. Which

Yes .. and no.

If we leave it up to each and every individual to make a decision on their own 
in a vacuum, then you are correct.

If we make thoughtful community/corporate encompassing goals then it is not 
left up to each individual: there will be a point of guidance that people can 
use to guide their decisions.

> means, the responsive KDE person needs to accept that a certain API needs
> to change for requirements NOT needed by KDE

This is a non-sequitor. If someone is using KDE libraries, then their 
requirements become part of what is needed by KDE. KDE is not a castle on a 
hill with a moat around it; it is an open marketplace where the edges are 
defined by participation.

> and the responsive person in
> Canonical needs to have interest in pulling in something that most likely
> can do way more than Ubuntu needs at this stage,

There is that word again: “likely” :) Every time I see that I think “.. it 
means we haven’t done the necessary homework to know for sure and so people 
are making assumptions”

There are two important points to consider:

a) Probably most libraries used do more than Ubuntu needs. Is every glibc call 
used by Ubuntu software written by Canonical? Is every Qt API used? (QWidget, 
e.g.)

b) If a library in KF5 is poorly modularized, resulting in something that does 
so much more than it ought to that we should reconsider the division lines 
within it, we need to know *now*. So if there is a KF5 library that would make 
sense being used in Unity (e.g.) but it does “way too much”, we can fix that. 
But we need to know.

> needed. It is not possible for me or Albert to go to some API guys and tell
> them: You have to share code with KDE. This needs to happen from inside the
> team. The person doing the work must drive it.

There must be leadership that can set engineering mandates?

> Now, coming from the Gnome/Gtk area, Canonical's people mostly are aware
> what code could be shared with Gnome, but not many of them have a clue what
> KDE frameworks actually is.

I’d just echo Thiago’s questions here, as they are truly insightful and key ..

> Same the other way round. I'm quite sure very
> few here know how the Ubuntu's architecture is built up.

Not many, I’m sure, but they exist. We have the Kubuntu folks and then there 
are crazy people like me who do look at what ends up in Canonical’s public 
repos and who have even done things like port apps written for Ubuntu Touch to 
other QML component sets. So the ignorance can be dissipated through effort!

> Then again, we actually do share and reuse some code. Take all the lightdm
> stuff for example, the dbusmenu stuff and many more libs which in history
> have flown into both directions already.

The status notifier stuff was a success, yes. I’d like to see that built upon so 
we have many more like that.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20130823/71a70620/attachment.sig>