"Cornelius's grand plan" - Merging KDElibs into Qt

[Aaron J. Seigo]

On Tuesday, November 2, 2010, Cornelius Schumacher wrote:
> On Monday 01 November 2010 Aaron J. Seigo wrote:

> The idea is about maintaining the KDE libraries in a different way, merged
> with Qt.

"merged with" needs further definition, imo. does it mean:

* lives in the same git hosting system (or even repository)

* ships alongside Qt releases (meaning we sync our release schedules)

* renaming classes

* rebranding libraries (not the same as renames in code)

* other properties?

there are so many things "merged with" can mean, and each have implications 
positive as well as negative to one degree or another. defining what is meant 
by "merged with" will be key so that we can:

* have a discussion amongst ourselves where we are actually discussing the 
same things (and not accidentally discussing different things but using the 
same words for them :)

* share the idea acurately with Qt Development Frameworks to work out buy-in 
(or not) from them

> So it wouldn't mean less work (well, maybe there could be some
> redundancies removed and free up some resources), 

:)

> but doing the work in a
> different way, more consistent with how it's done in Qt, more consistent
> for developers who would like to use the libraries.

similar with the term "merge with", this needs fine grain definition. what 
aspects of "how it's done in Qt" would we want to adopt or adapt to?
 
> For example the idea to create something like QtDesktop similar to
> QtMobility is neat.

implications of this are changing the granualization of our libraries. this is 
something some people (e.g. Kevin Ottens) are already working on, of course. 
figuring out what would belong in a QtDesktop module would be an interesting 
exercise.

much of kdelibs is not desktop specific, perhaps even most of it is not. off 
the top of my head things like the user interface bits in KIO, the widgets in 
libkdeui and the file dialogs are probably the best candidates for "desktop" 
categorization. we still have a lot of bulk left that doesn't fit that at all 
well, at least not without saying, "Well, our libraries are only useful for 
the desktop." this isn't true in fact, but we could still make such a 
statement. personally, i hope we wouldn't.

we'd also need to define what "Desktop" means clearly, covering things such as 
"where does it start and end on a spectrum of devices going from phones to 
tablets to netbooks to laptops to desktops to workstations to industrial 
control systems to..?" that definition will avoid us sucking things into 
Desktop that are actually applicable elsewhere.

i can see the utility of having a separation of some things that only makes 
sense for "mouse and pointer driven interfaces on larger screens", but in 
general looking at things from a device spectrum perspective makes a lot more 
sense to me. in a great world, i'd be able to use KComboBox and get something 
appropriate on a phone and a desktop when it is used. i may need a different 
layout for the UI it is in, but that specific widget need not be form factor 
specific. for non-UI items, it is often even more clear cut that they are form 
factor neutral (every platform regardless of form factor needs/wants 
configuration data storage, for instance) while others are more gray (async IO 
is important, does it need to be out of process?)

lots of details to fill in :)

> That would go into this direction. It of course needs
> a lot more investigation and concrete details to tell, if it makes sense.

yep...
 
> > imho Qt open governance is mature enough yet to realistically support
> > free
> 
> I suppose you meant "is *not* mature enough yet".

erp, yes. it is _not_ mature enough yet.
 
> > handed 3rd party involvement in development. when we (KDE) would need
> > something, it would result in a lot of asking Qt Dev Frameworks for
> > permission and convincing of others. right now, that's unlikely ime, and
> > when things are improved (and i do think they will) it will be less
> > efficient than what we have now due to the increased number of entities
> > involved.
> 
> That's a challenge for the Qt community and the people steering it. It

by joining the Qt community more directly, we would shift some of that 
challenge to ourselves. iow, it becomes our problem, at least in part.

> won't be easy, but things are improving, 

agreed

> participate and contribute. To what degree we in KDE want to be part of
> that, is up to us.

it is also partly up to the Qt community. if they don't want us or can't 
incorporate our involvement, then that will negatively impact our desire to be 
a part of it. if we wish to try this, we need to do so with not only our own 
priorities well defined, but to collaborate with Qt prior to making our 
decision and laying out shared goals, commitments and requirements.
 
> > so what exactly do people mean when talking about "merging with Qt"? not
> > broad brush strokes, but specific detailed goals.
> 
> Yes, and I'm happy to see how many good ideas and details already have been
> produced in this thread.
> 
> > you really can't plan the future of core assets like that.
> 
> I don't think we can talk about a plan yet. This started as brainstorming

i agree that we don't need a concrete, detailed plan. but what we do need are 
specific goals. without such goals being aggregated together, it'll be very 
hard to know which way to turn.  maybe you have a selection of such goals 
already in your mind. :)

the kinds of goals i'm thinking of would answer questions like:

* what do we want the impact on our end users to be?

* what kind of improvements do we wish to bring our application developers?

* what kind of inconveniences are we willing and not willing to put on our 
application developers?

* what do we want to achieve socially?

* what do we want to achieve in terms of market share from this?

* what kind of control do we wish to retain over our source code?

* what areas of collaboration with Qt do we want to see strengthened or emerge 
as a result?

* what parts of our workflow around kdelibs do we see as "required that we 
maintain", "are negotiable", "don't matter one way or the other" and "are 
currently negative and should be replaced"? which of those would we wish to 
address in a "merge with Qt" initiative?

* how much effort and (calendar) time are we willing and able to put into 
this?

* how much and what kinds of change in kdelibs are we willing to entertain?


i'm slightly concerned that if it becomes an open ended brainstorm for too 
long, we'll end up caught up in detail issues (like class naming and 
namespacing discussions) without a proper framework of expectations and goals 
to direct those conversations. i'm also concerned that without a survey of 
where we are and what we are wanting to change from that in slightly more 
concrete terms that some will not be in favor of it simply because it is full 
of unknowns (which is fair) and others will be in favor of the idea without 
basing that on any actual idea of what would actually be achieved, let alone 
what the benefits and risks are.

i'm glad to see this conversation started and think that it could be an 
excellent idea. it's also something that will be easy to get horribly, 
horribly wrong without serious planning. it's also something that could be a 
complete waste of time to do, though we will only know that once a more 
thorough assessment is done.

there have been mumblings about doing an "Appeal 2" type meeting. it's also 
been ~4 years since we got all the kdelibs people together specifically to 
talk about kdelibs. given the difficulty of the above, perhaps it makes sense 
to host such a meeting to come up with a clear set of goals, requirements, 
etc. for this initiative. "worst case" scenario is that we would come out of 
it knowing why we can't/won't do it and we'll have spent time and energy 
discussing something that won't happen; even then we'll emerge with a better 
understanding of what kdelibs is all about. "best case" is that we emerge with 
a crystal clear plan of how to proceed in the future, perhaps targeting a Qt 
merger.

i don't see this happening on a mailing list, though. it's not a great medium 
for the kind of exercises that really help with these sorts of deliberations, 
and not everyone that ought to be invovled is here (e.g. it might make sense 
to invite Lars Knoll to join such a meeting on the last day or two so we can 
pitch to him directly) ... 

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- 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-core-devel/attachments/20101102/33a0170d/attachment.sig>