sounds reasonable. a little sad that ubuntu 10.04 LTS will release kde 4.4, but on the same time a more fix orientated 4.5 will mean more backports to 4.4, and ubuntu will probably ship 4.4.2 (or 3). so that sounds nice. it also means a polished kde 4.5 will compete with gnome 3.0 which now has been delayed to september 2010.
now only lets hope my master studies get more relaxing so i can code more greetings beat Am Mittwoch 04 November 2009 00.41:48 schrieb Aaron J. Seigo: > hi all .. > > i spent some time today thinking about challenges as well as opportunities > that exist for our little Plasma baby who is growing up at an amazing pace. > > just to give you an idea of where we're at in terms of raw code production, > here are some sloccount counts: > > kdelibs: 42,121 > runtime: 4,190 > workspace: 83,332 > addons: 55,792 > > and we have so many little buds of progress elsewhere too: > > kdereview: 8,365 > media center components: 6,608 > plasmate: 4,518 > networkmanager: 27,029 > lionmail: 2,009 > mobile shell: 1,147 > > we have been pounding out feature packed release after feature packed > release and 4.4 will be no different in that regard. > > of course, it's not the only way we're growing. were also growing the user > base as more of our desktop users come online and we start to reach out > into new areas of the market such as netbooks and phones. we're also > growing in *dum de dum dum* bug count. right now we have 745 open bug > reports, not counting wishlist items. that's not as bad as it might sound; > it's somewhere around one bug per 240 lines of code. but it's still > substantial. > > as i mentioned at T3, plasma has developed a bit of a rhythm from release > to release: January brings lots of new features (esp big ones) and some > polish, July brings lots of polish and some new features (mostly smaller > ones). > > 4.4 will certainly be a big feature release: netbook, remote plasmoids, new > widget explorer, containment action plugins, lots more javascript in a > number of places, nepomuk integration .... but what about 4.5? > > well, i'm seriously considering putting a moratorium on new features in 4.5 > and instead focusing on making it a polishing release. > > when we started out with KDE 4, one of our goals was to create an object of > desire that people would pick over the "high end competition" such as > MacOS. we achieved so much towards that goal, and now our biggest sore > points are the little details. > > such a polishing release would consist of: > > * completing features that have made it thus far in a "mostly done" state > but not quite finished > > * cataloging and improving families of (mis-)features like this: > http://techbase.kde.org/Projects/Plasma/Plasmoid-Issues > > * a concentration on killing bugs right from the start of the release cycle > > * measuring memory and cpu performance and improving on both > > * tightening down our artwork and configuration UIs for consistency and > extra sparkle > > if we go ahead with this, then our pre-release IRC meetings and T4 would be > the where we would mark out our targets and decide how to tackle them. > > my concerns in such a move are: > > * it would destroy people's desire to work on plasma by making it more > boring and difficult than it currently is with all the emphasis on great > new things > > * people would ignore this set of goals and work on features anyways, > splitting our community up and causing some tensions we don't have with our > "wide open" policy > > * we wouldn't have enough to show at the end of it for our users to go > "wow" over > > if we decide that this is something we would like to take on, we would need > to make it fun and cool to do this hard work. i'd be sure to share bug > count stats, performance measurements and track our goals on a regular > basis to keep us moving. if new people came along with new features or we > found we Really, Really(tm) needed something (e.g. if we got some kick ass > bluetooth work donated), we'd have to be flexible enough to allow some of > that to happen but disciplined enough not to get sidetracked ourselves. > > now, i'm still working through all of the implications of this and really > haven't decided yet whether it's the best of ideas yet. and it would > absolutely require that the overwhelming majority of our team here would > want to see this through. > > so i put the question to you: what do you think? should we do this? should > we not? why? why not? > > (and just to head off all the "oh yes, please do!" comments from the people > on the list here who follow the threads but who aren't active contributors > to some part of plasma: let's keep this discussion to those who are > working on the code and artwork for now. thanks :) > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
