thinking ahead to 4.5: features or polish?
Shantanu Tushar Jha
jhahoneyk at gmail.com
Wed Nov 4 14:24:25 CET 2009
On Wed, Nov 4, 2009 at 5:11 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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
+1 on this, its something that really counts, not everyone has a high
performance machine. They shouldn't miss the coolness Plasma has to
offer.
>
> * 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
Its not that boring fixing such bugs, it gives a lot of satisfaction
once you fix some performance/usability problem.
>
> * 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
No, If a Plasma release removes some misbehaviors (such as Plasma
crashing without any apparent reason from the user's point of view),
it can be the best gift for the user. (e.g. I really hated it when
once I had important notes written, then Plasma crashed and somehow my
notes disappeared)
>
> 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?
I'm just a student right now and been promoting GNU/Linux usage among
my friends at college. Before KDE 4.2 came out, I recommended GNOME to
everyone. But now, I tell them KDE is the best environment, the reason
that its more polished than 4.1. Tens of my friends now use KDE as
their regular desktop. (Everyone confused it with Win7 when I showed
them KDE 4.3 few weeks ago and it was like "cool man, thats great!!").
But, people still complain me that xyz feature of Plasma behavior is
strange, and something which can be seen everyday in "bugs reported
today" is "Plasma crashed when doing xyz". We need to make Plasma
reliable so that the user can trust the system, features which aren't
robust are hardly of any use.
So, This should be done, but it shouldn't be like "No features, stop".
We should just put more emphasis on polish, but still let features to
come in.
>
> (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 :)
>
> --
> 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
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
--
Shantanu Tushar (UTC +0530)
http://www.shantanutushar.com
More information about the Plasma-devel
mailing list