kde-quality Digest, Vol 19, Issue 7

[Michael Pyne]

On Sunday 14 August 2005 18:30, C. Michailidis wrote:
> 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.

Well given your description of the problem (which was admittedly possibly a 
poor recollection), I would agree that if it happened, it was a BSD ports 
problem.  KDE actually has a long history of being quite modular.

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

It's a start, but as you surmised a backtrace is much more useful with debug 
info, since not only does it include exact line numbers, but it typically 
displays the values of the local variables.  For instance, this enables 
developers the change to see if we're dealing with a simple null pointer 
dereference versus something more serious like trying to dereference a 
garbage memory location.

> > > 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.

Well, as always, if the version you have works for you, then there's really no 
reason to upgrade.  An upgrade is typically done for bugfixes and new 
features.  If you don't need new features, and if you aren't having troubles 
with annoying bugs, sometimes it makes more sense not to upgrade.

As Aaron has been trying to point out, we can't be perfect all the time, 
especially when we are typically the only ones actually testing the software.  
For example, it would be incredibly helpful if some people could run their 
stable KDE (3.4 in this case) from Subversion instead of using the releases.  
That way if we introduce a bug, it can be caught and fixed before we release 
a buggy upgrade on accident.

I have authored a tool kdesvn-build which aims to make this kind of thing 
easy.  Or at least, easier than it used to be.  It would be helpful even if 
it meant only tracking one KDE module as opposed to most of KDE.  For 
example, kdelibs and kdebase.

> > > 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.
>
> 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.

Freezes *do* occur of course.  Typically this is a period of much griping 
among the devs, but they do happen.  They *don't* really happen for releases 
of the stable branch unfortunately.  To make matters worse, most devs don't 
run the stable branch (which in theory needs less testing anyways.  After 
all, it's stable...).  Again, this is an area where support from our users 
could go a very long way.

> > > 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?

You are using the stable branch (and the latest release thereof).  The other 
choices are:

The final development branch for KDE 3, which will become KDE 3.5, or
The development branch for KDE 4 (which is still in a state of disarray).

> > creating a branch doesn't generate bug fixes, however. q/a testing and
> > patches generate bug fixes.

I'd settle for good Q/A testing myself, but patches are certainly appreciated.

> > > 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.
>
> 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'.

You mean something like a stable KDE base libraries collection with an 
evolving collection of KDE applications?  I belive stuff like this has been 
proposed but for now KDE 3.4 applications depend on KDE libs 3.4 and don't 
receive new features.  If you were to use KDE 3.5 applications they'd need 
KDE 3.4 (with some notable exceptions, I believe the KDE 3.5 PIM packages 
don't require KDE 3.5).

> > 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.

And that's exactly the split we have.

> 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?

Well the first line of defense are, of course, the developers.  Unfortunately, 
the second line of defense between devs and users, the Q/A dept., doesn't 
really exist as an organized group.  Trust me, we'd ABSOLUTELY LOVE to have a 
group dedicated to doing nothing but Q/A'ing KDE, but as yet we're relying on 
user support (through the KDE Quality project) to catch things that the devs 
don't.

> > 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?

No, bitching describes a bug report without a "Bug Report". ;-)  As far as 
anger goes, he's been a dev longer than I have.  None of us mean to, but over 
time we get just as stressed as people in any other profession.

> 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?

Yes, of course.  But you have to understand that what I think he was trying to 
explain was that KDE could be getting more stable for all you know (and that 
has been my experience), although it doesn't seem like it to you because you 
managed to encounter the star-crossed set of bug regressions...

> > > 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'".

No need to be pedantic, you know what he meant.  The point remains though, we 
can't know before a release if something breaks for someone if no one tests 
it.  This is not a problem unique to KDE.  You'll hear Linus complaining 
about the lack of testing on every other day it seems, and the Linux kernel 
guys even have a rather impressive testing structure.

> > > 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.

I would go out on a limb and say that most KDE devs prefer stability over 
bells and whistles as well.  Of course, a fix that makes a program more 
stable while also adding something useful is just icing on the cake.

This is why, for instance, new bells and whistles are forbidden from the 
stable branch.  That's right: KDE devs are only allowed to bugfix the stable 
branch, new features are not allowed.  So, an upgrade from KDE 3.4.x to 
3.4.x+1 should *always* be a more stable, refined KDE experience.  If it's 
not, for some reason, we need to know.

> 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.

Come on, it's can't be that awful. :P
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-quality/attachments/20050815/aa75cd9c/attachment.pgp