Hi Clemens, On Thursday, 2011-04-14, Clemens Eisserer wrote: > The problems I see are: > 1. Too few developers, too much code > 2. Too short release cycles & Quality testing > 3. Features count most mentality. > 4. Performance > > I normally wouldn't bother the list with my ideas, however I have been > encouraged to do so. Appreciated. Most items seem to be to the point though I think some might be based on a bit of misunderstanding. > Ad 1.) > I participated during the kde 4.2/4.3/4.4 beta phase - and came to the > conclusion it was mostly > worthless effort on my side. There are simply not enough contributors > arround to fix all the open issues. > I have already a few projects I contribute to, fixing the bugs myself > is simply no option :/ This is unfortunately true. One problem is of course the increasing code base over the years, adopting the platform and applications to newer requirements. IMHO this part of change in ratio of developers to lines of code would in itself not be a problem per se as only major transition points like Qt3 -> Qt4 make going through a lot of code necessary. The main problem of is "losing" long term contributors, because it is not the amount of developer available which counts but the amount of knowledge each developer has on the part of code they are working on. Some spots are of interest to many people and as such find even new maintainers easily. Others not as lucky, e.g. printing. Initially there was hope (correctly IMHO) that Qt4's improvements over Qt3 in this area (e.g. built-in PDF generator) would allow KDE to rely on its dependencies a bit more. In this case we were unfortunately let down, so it took a while until some brave soul put this topic onto their (already quite full) plate. Thanks John! > Furthermore KDE accumulated tons > of code over time (I still don't see the reason it carries its own > Office-Suite, HTML-Rendering engine, instant messanger, Media Player, > whatever), but only few guys are actually working on the code. Lets do the easy one first: HTML-Render engine API and ABI compatibility and no desire to go for KDE5 right now. Office-Suite is most likely referring to KOffice, Media Player probably to Amarok. Neither of which is part of a KDE software compilation release, thus not bound to any release schedule. Instant messenger and Media Player (in case this refers to something else): true, mostly a result of sharing libraries between applications which are not deemed to be API/ABI stable enough (yet) to be considered platform. It might be possible (and maybe even desirable) to allow each module to have its own release cycle. > Ad 2.) > Another problem is the release cycle. The cycle is so short, that even > many bugs reported during > alpha stage aren't fixed. At release-time, devs are already working on > new features, often not backporting their fixes. > So you end up again with release+1, this time with other bugs. > > Its not uncommon for me to see integral parts broken after updating to > a new major (like the panel in my multimonitor setting when updating > to 4.6). I don't think it is actually the length of the release cycle itself, my guess is that it is more of a question of the ratio between unfrozen and frozen periods within the cycle. This is one of the things that hopefully will get better due to the recent switch to git as our version control system. While SVN did support branching, tracking changes across several branches became quite difficult, resulting in most development to happen in trunk. git is a lot better in this regard, allowing development parallel to several releases, i.e. basically making it possible to only fold back fully implemented new features. So each release cycle's unfrozen period could be shortend considerably, e.g. like the Linux kernel's merge windows. > Ad 3.) > Features count most. Plasma may still be not completly stable, > and the TaskManager may do weird things (both from a user perspective > absolute core-components), > however wee see social network integration and whatever. I don't think this is true across the spectrum of KDE products, though it is definitely more prevalent in the workspace area. My take is that this area is the one with most changes in requirements and also competition so developers there might be inclined to work on new challenges when the current solution works reliably for them. E.g. attemping a different implementation based on QML and its scenegraph inspite of these technologies not being very stable yet. > Ad 4.) > I remember KDE4 was praised for using less memory and beeing faster than > 3.5. I knew that would't become reality, 4.6 uses about twice the amount > of memory 3.5.11 used and starts up way slower. > Paint performance is mostly bad, but instead of improving the painting > all simply paint to X11/Xorg and praise the QT-Raster backend which is > here to solve all problems. > Guys, XRender has arrived and is implemented by drivers well. If QT / > your code can't use it - don't blame X11. Well, according to the developers who came up with XRender, it is basically just a stop-gap measure to get some features potentially hardware accelerated while fitting close enough to the usual X11 API. (And it depends on the Xserver implementation being used, got bitten by that at work when a customer was using one of these proprietary Xservers, yuck). For Qt, the raster graphicsystem is actually quite good, even default on Windows, but on X11 the default is still X11 with Xrender. Using raster might actually make things faster (it did on Windows, so why not also on X11). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Attachment:
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
