On Sunday, October 31, 2010, Mark Kretschmann wrote: > What do you think about it?
i think it isn't a plan as much as it as an open ended question that we really don't have the ability to answer very well right now. unfortunately, it was also positioned on some rather dubious claims such as: "Over the last couple of years, KDE development has constantly shifted from library development to application development. Our struggles with even just doing the basic maintenance of the libraries show that. [...]There are still brave souls taking care of kdelibs, but it's really hard to keep up there." this is a line we've been telling ourslves for at least 6 years now. compare kdelibs now to then and the facts don't particularly align with the scary scenario outlined above. more importantly, if we look at Qt we can find all kinds of poorly or outright unmaintained stuff that causes issues because it is so. which means that merging with Qt willl not, in the least, resolve this kind of issue for us. we should not delude ourselves there, because if we decide to pursue such a course of action we need to not do so with the expectation that our need to work on libraries will suddenly evaporate or significantly lessen in some way. as for MeeGo as the aims there, i don't think there is nearly the overlap between MeeGo's goals and the goals of kdelibs that Cornelius seems to perceive. MeeGo is very specific and very pragmatic about caring about one specific platform. i've seen the result of that first hand, and it isn't something i see as being particularly healthy for generic libraries that come under its umbrella since product release schedules and "it needs to work for our consumer electronic product" trumps all. but looking at the idea squarley, the first question i think of is: What does "merge with Qt" mean, exactly? dicing up our libraries a bit differently, hoping to get them shipped with Qt? changing the release cycle to match that of Qt's? moving kdelibs code development to gitorious alongside Qt? merging code into existing Qt libraries, and if so which kde code and which Qt libraries? are we doing this primarily for technical gain, primarily for marketing gain, or for some mix of both (and to what extent)? these questions matter because: imho Qt open governance is mature enough yet to realistically support free 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. if it is about reaching the broader audience of the Qt develper world, it's a bit more than "shove it all into Qt". we need to understand what would make such libraries attractive. in the 2 threads on this already we've seen some are hesitant about the large dependency chains, including how that looks on non-Linux/UNIX platforms. mergin with Qt doesn't solve that set of issues in the least, and simply thinking that merging with Qt means the dependencies go away or that we can get rid of those dependencies without impact on our applications (the whole point of our libraries) is probably a bit simplistic. so what exactly do people mean when talking about "merging with Qt"? not broad brush strokes, but specific detailed goals. on the kdelibs side, we have several kinds of functionality. i think Michael Jansen did a very good job of outlining the differences in his first email in this thread. not everything in kdelibs will be of interest in the scope of Qt, though much of it will continue to be of interest to our applications. if anyone is really truly serious about taking on such a "merging with Qt" project, the first thing that problably needs to be done after identifying specific detailed goals is a class-by-class census of what is in kdelibs right now. break them out by what kind of functionality they provide and what they are appropriate for. start to draw out what the resulting library set would look like from an application developer's POV. some of this work has already been done, e.g. with solid. it might make sense to identify which parts are ready _right now_ and start working those "into Qt" in a way that is an improvement over the methods used for Phonon or printing. it would help build paths and slim the profile of kdelibs while openning the door to our libraries to more developers ... without a huge "merge kdelibs with Qt" concept at the outset. in summary, i think the picture of being involved with Qt at this point in time was painted a bit more optimistically than the reality of it and the details of what it would mean for kdelibs has not been filled in at all. i don't think it is reasonable to ask anyone to have an opinion on the idea of merging kdelibs with Qt until both the state of Qt and kdelibs as relevant to that goal have been detailed. it could work out great, it could be a disaster, it could be a lot of work for a little gain ... we just can't tell right now because it's nothing more than a vague idea. you really can't plan the future of core assets like that. -- 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
signature.asc
Description: This is a digitally signed message part.
