From kde-core-devel Tue Nov 02 18:44:44 2010 From: "Aaron J. Seigo" Date: Tue, 02 Nov 2010 18:44:44 +0000 To: kde-core-devel Subject: Re: "Cornelius's grand plan" - Merging KDElibs into Qt Message-Id: <201011021144.45367.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=128872352819774 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart5254817.JvlLC4TjIE" --nextPart5254817.JvlLC4TjIE Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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= =20 positive as well as negative to one degree or another. defining what is mea= nt=20 by "merged with" will be key so that we can: * have a discussion amongst ourselves where we are actually discussing the= =20 same things (and not accidentally discussing different things but using the= =20 same words for them :) * share the idea acurately with Qt Development Frameworks to work out buy-i= n=20 (or not) from them > So it wouldn't mean less work (well, maybe there could be some > redundancies removed and free up some resources),=20 :) > 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= =20 aspects of "how it's done in Qt" would we want to adopt or adapt to? =20 > 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=20 something some people (e.g. Kevin Ottens) are already working on, of course= =2E=20 figuring out what would belong in a QtDesktop module would be an interestin= g=20 exercise. much of kdelibs is not desktop specific, perhaps even most of it is not. of= f=20 the top of my head things like the user interface bits in KIO, the widgets = in=20 libkdeui and the file dialogs are probably the best candidates for "desktop= "=20 categorization. we still have a lot of bulk left that doesn't fit that at a= ll=20 well, at least not without saying, "Well, our libraries are only useful for= =20 the desktop." this isn't true in fact, but we could still make such a=20 statement. personally, i hope we wouldn't. we'd also need to define what "Desktop" means clearly, covering things such= as=20 "where does it start and end on a spectrum of devices going from phones to= =20 tablets to netbooks to laptops to desktops to workstations to industrial=20 control systems to..?" that definition will avoid us sucking things into=20 Desktop that are actually applicable elsewhere. i can see the utility of having a separation of some things that only makes= =20 sense for "mouse and pointer driven interfaces on larger screens", but in=20 general looking at things from a device spectrum perspective makes a lot mo= re=20 sense to me. in a great world, i'd be able to use KComboBox and get somethi= ng=20 appropriate on a phone and a desktop when it is used. i may need a differen= t=20 layout for the UI it is in, but that specific widget need not be form facto= r=20 specific. for non-UI items, it is often even more clear cut that they are f= orm=20 factor neutral (every platform regardless of form factor needs/wants=20 configuration data storage, for instance) while others are more gray (async= IO=20 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... =20 > > imho Qt open governance is mature enough yet to realistically support > > free >=20 > I suppose you meant "is *not* mature enough yet". erp, yes. it is _not_ mature enough yet. =20 > > 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. >=20 > 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=20 challenge to ourselves. iow, it becomes our problem, at least in part. > won't be easy, but things are improving,=20 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=20 incorporate our involvement, then that will negatively impact our desire to= be=20 a part of it. if we wish to try this, we need to do so with not only our ow= n=20 priorities well defined, but to collaborate with Qt prior to making our=20 decision and laying out shared goals, commitments and requirements. =20 > > so what exactly do people mean when talking about "merging with Qt"? not > > broad brush strokes, but specific detailed goals. >=20 > Yes, and I'm happy to see how many good ideas and details already have be= en > produced in this thread. >=20 > > you really can't plan the future of core assets like that. >=20 > 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 a= re=20 specific goals. without such goals being aggregated together, it'll be very= =20 hard to know which way to turn. maybe you have a selection of such goals=20 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= =20 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 eme= rge=20 as a result? * what parts of our workflow around kdelibs do we see as "required that we= =20 maintain", "are negotiable", "don't matter one way or the other" and "are=20 currently negative and should be replaced"? which of those would we wish to= =20 address in a "merge with Qt" initiative? * how much effort and (calendar) time are we willing and able to put into=20 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= =20 long, we'll end up caught up in detail issues (like class naming and=20 namespacing discussions) without a proper framework of expectations and goa= ls=20 to direct those conversations. i'm also concerned that without a survey of= =20 where we are and what we are wanting to change from that in slightly more=20 concrete terms that some will not be in favor of it simply because it is fu= ll=20 of unknowns (which is fair) and others will be in favor of the idea without= =20 basing that on any actual idea of what would actually be achieved, let alon= e=20 what the benefits and risks are. i'm glad to see this conversation started and think that it could be an=20 excellent idea. it's also something that will be easy to get horribly,=20 horribly wrong without serious planning. it's also something that could be = a=20 complete waste of time to do, though we will only know that once a more=20 thorough assessment is done. there have been mumblings about doing an "Appeal 2" type meeting. it's also= =20 been ~4 years since we got all the kdelibs people together specifically to= =20 talk about kdelibs. given the difficulty of the above, perhaps it makes sen= se=20 to host such a meeting to come up with a clear set of goals, requirements,= =20 etc. for this initiative. "worst case" scenario is that we would come out o= f=20 it knowing why we can't/won't do it and we'll have spent time and energy=20 discussing something that won't happen; even then we'll emerge with a bette= r=20 understanding of what kdelibs is all about. "best case" is that we emerge w= ith=20 a crystal clear plan of how to proceed in the future, perhaps targeting a Q= t=20 merger. i don't see this happening on a mailing list, though. it's not a great medi= um=20 for the kind of exercises that really help with these sorts of deliberation= s,=20 and not everyone that ought to be invovled is here (e.g. it might make sens= e=20 to invite Lars Knoll to join such a meeting on the last day or two so we ca= n=20 pitch to him directly) ...=20 =2D-=20 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 --nextPart5254817.JvlLC4TjIE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAkzQXB0ACgkQ1rcusafx20N49wCfe3UDC5sZ0LNugq0lhjwjHPhi tI4An0Pt7f7knXyIdQ7AuhhRRw5YJwGm =pd70 -----END PGP SIGNATURE----- --nextPart5254817.JvlLC4TjIE--