kde-quality Digest, Vol 19, Issue 7

[C. Michailidis]

I'm just asking to be flamed for posting such a huge message... eh, I'll risk it.

On Sunday 14 August 2005 03:27 pm, Aaron J. Seigo wrote:
> On Sunday 14 August 2005 11:38, C. Michailidis wrote:
> > hour or more to build kde-base only to see that it tries to over write a
> > file from kde-lib (or w/e, i can't quite remember the details now) and then
> 
> sounds like the BSD ports have problems.

Sounds a bit hasty to be pointing the finger at the BSD folks to me.  Especially given that KDE is the only one out of 400+ ports that it has been a recurring issue with.

> > Next, I go to sync my visor w/ kpilot and I notice that Kpilot crashes
> > every time I click on 'memos' or 'addresses'.  Kpilot sync's fine with the
> > visor, but I can no longer view my memos... It's really aggravating.
> 
> backtraces?

Sorry, I don't have debug info available but maybe you're interested in it anyway:

[Switching to LWP 100141]
0x2951ab8f in wait4 () from /lib/libc.so.5
#0  0x2951ab8f in wait4 () from /lib/libc.so.5
#1  0x2950bfaf in waitpid () from /lib/libc.so.5
#2  0x294af0ad in waitpid () from /usr/lib/libpthread.so.1
#3  0x28a09399 in KCrash::defaultCrashHandler ()
   from /usr/local/lib/libkdecore.so.6
#4  0x294b5928 in sigaction () from /usr/lib/libpthread.so.1
#5  0xbfbfff94 in ?? ()
#6  0x0000000b in ?? ()
#7  0xbfbfdbf0 in ?? ()
#8  0xbfbfd930 in ?? ()
#9  0x00000000 in ?? ()
#10 0x294b558c in sigaction () from /usr/lib/libpthread.so.1
#11 0x08072b66 in MemoWidget::showComponent ()
#12 0x0806f653 in PilotComponent::showKPilotComponent ()
#13 0x08069972 in KPilotInstaller::slotAboutToShowComponent ()
#14 0x08067f57 in KPilotInstaller::qt_invoke ()
#15 0x28e413b6 in QObject::activate_signal ()
   from /usr/X11R6/lib/libqt-mt.so.3
#16 0x2878c7d9 in KJanusWidget::aboutToShowPage ()
   from /usr/local/lib/libkdeui.so.6
#17 0x2878c936 in KJanusWidget::qt_emit () from /usr/local/lib/libkdeui.so.6
#18 0x28e41448 in QObject::activate_signal ()
   from /usr/X11R6/lib/libqt-mt.so.3
#19 0x2915eb39 in QWidgetStack::aboutToShow ()
   from /usr/X11R6/lib/libqt-mt.so.3
#20 0x28f68c86 in QWidgetStack::raiseWidget ()
   from /usr/X11R6/lib/libqt-mt.so.3
#21 0x2878ad33 in KJanusWidget::showPage () from /usr/local/lib/libkdeui.so.6
#22 0x2878acad in KJanusWidget::showPage () from /usr/local/lib/libkdeui.so.6
#23 0x2878ac54 in KJanusWidget::slotShowPage ()
   from /usr/local/lib/libkdeui.so.6
#24 0x2878c85d in KJanusWidget::qt_invoke () from /usr/local/lib/libkdeui.so.6
#25 0x28e413b6 in QObject::activate_signal ()
   from /usr/X11R6/lib/libqt-mt.so.3
#26 0x28e412ca in QObject::activate_signal ()
   from /usr/X11R6/lib/libqt-mt.so.3
#27 0x2914f11a in QListBox::selectionChanged ()
   from /usr/X11R6/lib/libqt-mt.so.3
#28 0x28f054a7 in QListBox::setSelected () from /usr/X11R6/lib/libqt-mt.so.3
#29 0x28f02aeb in QListBox::mousePressEventEx ()
   from /usr/X11R6/lib/libqt-mt.so.3
#30 0x28f02962 in QListBox::mousePressEvent ()
   from /usr/X11R6/lib/libqt-mt.so.3
#31 0x28e74e76 in QWidget::event () from /usr/X11R6/lib/libqt-mt.so.3
#32 0x28de893d in QApplication::internalNotify ()
   from /usr/X11R6/lib/libqt-mt.so.3
#33 0x28de7fdd in QApplication::notify () from /usr/X11R6/lib/libqt-mt.so.3
#34 0x2897a74d in KApplication::notify () from /usr/local/lib/libkdecore.so.6
#35 0x28d84737 in QETWidget::translateMouseEvent ()
   from /usr/X11R6/lib/libqt-mt.so.3
#36 0x28d8237e in QApplication::x11ProcessEvent ()
   from /usr/X11R6/lib/libqt-mt.so.3
#37 0x28d97e05 in QEventLoop::processEvents ()
   from /usr/X11R6/lib/libqt-mt.so.3
#38 0x28df9b2b in QEventLoop::enterLoop () from /usr/X11R6/lib/libqt-mt.so.3
#39 0x28df9a84 in QEventLoop::exec () from /usr/X11R6/lib/libqt-mt.so.3
#40 0x28de8a94 in QApplication::exec () from /usr/X11R6/lib/libqt-mt.so.3
#41 0x0806ecad in main ()

> > fooooooreeeevvveeerrrr to load the page.  This problem 'magically' vanished
> > after the last portupgrade I did.
> 
> i'm a bit lost here: in this case the last upgrade was a good thing?

I guess so, and that's my point exactly.  The concept I'm trying to convey is that (given my personal experience mantaining and updating KDE) it's easy to 'not have much faith' in the newer version.

> > I'm pretty sure that when Mr. van Hoose says "KDE's development needs to be
> > stopped" he means that at one point the kde code has to freeze and only
> > accept bug fixes, not new features. 
> 
> which is a wonderfully quaint idea often posed by those who only have a view 
> of things from the outside.

The outside??  Are they keeping you prisoner over there, lol!  Do you need us to send you a cake with a lock-pick baked in? ;-)  Is it such a 'quaint' idea because no one over there can show self restraint?  I understand that its easier said than done but for crying out loud, if it is such a monumental task it would raise serious questions about 'kde quality' in my mind.  I've worked on a number of software projects myself (ranging from 4 developers to 40 developers), and I would have to say that in all the "high quality" environments the goup was always able to freeze the addition of features for a somewhat extended period of time until the desired milestone was reached.  This milestone could be nearly anything but typically it would be something concrete... warnings per line of code, a limit on the number of outstanding bugs, simple acknowlegement of acceptence by end-users, etc.

> > I know that many 'larger' projects 
> > tend to have multiple source code branches to work from.  Is there such a
> > thing as this in kde-land? 
> 
> yes, of course there is.

In that case, maybe I'm just using the wrong one?  Can this be confirmed?  When I type 'pkg_info | grep -i kde-' it says:

kde-3.4.2           The "meta-port" for KDE

Is there an alternative?

> 
> creating a branch doesn't generate bug fixes, however. q/a testing and patches 
> generate bug fixes.
> 
> > The reigns need to be pulled in a bit. 
> 
> so we pull in the reigns and i don't add "mirrored panels" support and then 
> you complain that there isn't support for "mirrored panels". no, this doesn't 
> work.

Boy, you are a pessimist!  And since when did this discussion become about you?  If I want mirrored panels that bad I can take care of it myself... the topic is kde-quality not self-pity.  Some people prefer stability to new features, some people prefer the opposite.  Since it's nearly impossible to have both, offering a choice would be a good thing.  I understand that it is a double edged sword.  I really didn't mean to make a big stink about 'mirrored panels', indeed I am using the workaround of 'duplicate panels' (if you will) more or less happily.  To me quality isn't just a feature list, I also award points for stability, elegance, performance, etc.  Naturally, no one gets a perfect score.  That's why my only real suggestion (at least the one I wanted to get across) was to offer an alternative version of 'new stuff' and a stable version of 'core stuff'.  Maybe I didn't describe this well enough.  Apparently, something of this nature exists but I wasn't aware of it.  Well, I'm just a typical lazy end user; if I am not made aware of it I'll likely not stumble across it for a while.  If this is really the case, I'm surprised that when I type 'make search key=kde | grep -i Port:' I don't see a kde-dev/kde-prod or kde-beta/kde-stable or kde3/kde4, I only really see kde-lite-3.4.0 and kde-3.4.0.  If someone can point me in the right direction I would appreciate it.

> 
> what does happen, however, is that we go and implement something (sometimes a 
> feature, sometimes and optimization, sometimes a bug fix, sometimes a bit of 
> each) ... this changes the application and it may now cause that app to fail 
> in a particular configuration.
> 
> the kpilot author(s) don't have a wall with every possible device in every 
> possible configuration on every possible OS with which to test every change. 
> even if they did, they'd still need the time to do the testing. this is where 
> you come in, and one of the purposes of this list, really: get to testing the 
> software before it is released to help identify and target bugs.

I understand this.  However, most quality software I've worked with in the past has some (more or less obvious) method of choosing a 'stable' vrs an 'experimental' distribution.  Are the kde developers hoping to use new users as guinea pigs in all cases?  I can't agree with that kind of thing.  I would imagine some KDE people are assigned to QA responsibilities, no?

> 
> sitting back and bitching about it results in zero beneficial change. zero. 
> getting involved (which means more than subscribing to a mailing list) 
> results in beneficial change, however.

C'mon, it just sounds like you're venting anger now.  Isn't 'bitching' just another way to describe a bug report?  Plus, I'm entitled to my opinion.  If I want to believe that KDE is a nice desktop that offers a bunch of cool features but can be lacking on the stability/usability side I'm entiled, aren't I?  By the way, beneficial change can come in many forms... not just unified diffs and bug reports.  Beneficial change can come about from the exchange of thoughts and ideas once in a while too.  Honestly, you've hurt my feelings a bit... my previous email didn't offer any benefit at all, you didn't even crack one smile or empathize in any way??? :(

> > Some users 
> > don't want to be guinea pigs for the latest and greatest stuff.  In fact,
> 
> then don't complain when your visor doesn't sync. this is how this process 
> works.

Lol, I said that... "Kpilot sync's fine with the visor".  The problem is: "Kpilot crashes every time I click on 'memos'".

> > most users (especially corporate types) simply want a robust, refined, and
> > highly usable solution without the bells, whistles, and eye-candy.  Maybe
> 
> i wish.

Okay, you got me here... it is *my opinion* that users want stability over bells and whistles.  But again, does history define the man, or does the man define history?  If the kde developers value bells and whistles over robust, refined, and usable solutions then users will certainly be of a similar breed, and the software quality will reflect the mindset.  It's amazing (actually) how much this rings true even when simply comparing the visual asthetics of kde and say gnome or enlightenment.  Do you agree?

> 
> > I'm just not familiar enough with the release engineering process being
> > used; Honestly, I don't even know of a stable/dev branch of kde, nor have I
> > ever seen any beta vrs production releases of it.  Almost every
> 
> and yet you've said in this very email you are using it.

It's possible to be unfamiliar with something and still use it, right?  Am I on trial here?

> > Otherwise, I just may switch back to windowmaker ;-)
> 
> perhaps you should. i hear they have a great visor syncing program.

Ah yes... the bitter taste of sarcasm.  You can take all the cheap shots at windowmaker that you want, I still like it.  Honestly, you seem offended.  I didn't mean to make you feel that way, I like KDE too!

I'll tell you, right now the biggest reason I tend to use KDE+kontact instead of gnome+evolution or wmaker+whatever...  ready?  I like that kde exposes the advanced window option of showing the border, that's (more or less) it.  It's a nice feature.  Of course, that option may actually be available in gnome or wmaker or enlightenment or etc, and I just don't know about it.  Other than that almost everthing is just icing on the cake for me.  Of course, if you find glass shards in the icing the cake starts to taste really bad.

Lol, the visor syncs fine.