4.3.3 bugs

[James Tyrer]

Duncan wrote:
> James Tyrer posted on Wed, 11 Nov 2009 19:02:46 -0700 as excerpted:
> 
>> Duncan wrote:
>>> Anne Wilson posted on Wed, 11 Nov 2009 11:43:25 +0000 as 
>>> excerpted:
>>> 
>>>> On Wednesday 11 November 2009 11:08:50 James Tyrer wrote:
> 
>>>>> 1.	Auto completion doesn't work in Konqueror (and other 
>>>>> places).
>>>>> 
>>>> Not sure what you mean here, but in Konqueror if I start a url 
>>>> I'm offered a list of sites already visited.
>>>> 
>>>>> This is very frustrating since as you type, the list of 
>>>>> suggested completions opens, but when I try to move the mouse
>>>>>  to select one, the list immediately closes.
>>>>> 
>>>> It works here.  No problem
> 
>>> As with Anne, this definitely works for me.
> 
>> Well, I first note that this is only an issue when using KDE-4.  It
>>  worked with KDE-3 and it works in Firefox.  And, it works when 
>> using the history list with the location in Konqueror.  So, there 
>> probably is a KDE-4 problem with X11 and the issue could be in X11.
>>  X11 has been in a state of flux.  Now that 7.5 has been released, 
>> perhaps things will be resolved.  Are you using xorg-server-1.7.1 
>> yet?
>> 
>> Specifically, it could be a problem with: "xf86-input-mouse".  But 
>> I upgraded to 1.5.0 and it didn't help.
> 
> I'm on xorg-server-1.7.1, yes.  But you could have something with the
>  input driver.  I've been using the xf86-input-evdev driver (2.3.0 
> currently) for some months now.  It's nice to be able to use the same
>  driver for both mouse and keyboard, for one thing.  The switchover 
> to hal- autodetect was a bit rough, especially for keyboard as I had 
> to figure out how to tell hal to use the correct "inet/media" 
> keyboard instead of the default 101-key and that's not the 
> friendliest thing in the world to try to configure, but before that, 
> I had it set in xorg.conf, with Option "AllowEmptyInput" "no" set in 
> the serverflags section as well, so it wouldn't ignore the xorg.conf 
> settings.  That worked fine.
> 
I need to upgrade Xorg.  However, I am using PS/2 connected mouse and
keyboard.  Can I use xf86-input-evdev with non-USB input devices?

>>>>> 2.	Select Folder dialog doesn't do 'hidden' files.
>>>>> 
>>>>> Best place to test this is in System Settings: General -> 
>>>>> About Me:: Paths.  Try to set the Autostart Path.  So, you 
>>>>> start at Home.  The ".kde4" directory isn't listed, so enter 
>>>>> "/." and you get a list, but I can't use the mouse to select 
>>>>> from them but see #1.  IAC, you wind up having to type the 
>>>>> whole path.
>>>>> 
>>>> It works here, and always has done as far as I can remember
> 
>>> My setup is such that I can't confirm this one either way, here. 
>>> I can confirm that I don't see .* aka "hidden" files [but...]
> 
> Based on kishore's post, I checked the context menu in the tree view,
>  and sure enough, there was a view hidden dirs checkbox.  After 
> checking it, I saw the .kde and .kde4 symlinks along with others.  So
>  that seems to work as intended.
> 
> The bug would then lie in the the discoverability of said option.

I didn't even look for a context menu. :-(  So, I guess that this is a
HIG/usability issue.  Wouldn't it be better to have a toolbar, menubar,
or icon? -- like in the KFile dialog.

> Unless one happens to secondary-button click in the treeview, there's
>  no indication that a hidden-files option exists.  That could 
> befuddle the newbie, and even for folks as experienced as both you 
> and I are, it is non-obvious enough we had to have it pointed out. 
> There should be an options icon or something, somewhere, probably 
> beside the new-folder button, for toggling hidden-files-view.
> 
Like the wrench icon in the KFile dialog.  That also makes it a
consistency issue.

Also, now that I found the context menu, I find another serious
usability bug/issue.  It has: "Delete" (which I understand that you
like) despite the fact that I have not checked the box for: "Show
'Delete' command" in File Management -> General.

> As with some of the others, not a big issue, but certainly a UI 
> finish and polish issue.  I'd certainly suggest checking to see if a 
> bug is filed on this, and filing one if necessary, as it's the type 
> of bug Ubuntu's 1000 papercuts project (for example) would tackle, 
> not that significant in itself and should be quite easy to fix, but 
> would be very nice to have a visually discoverable 
> hidden-files-view-button by 4.4. (Maybe it's already fixed in the 4.4
>  branch and they just can't add it to 4.3?)
> 
>>>>> 3.	Select Folder dialog won't go to the "Root" place.
> 
>> You have to wonder though if the developers ever used it.  It 
>> appears to me that it should not be necessary to report things such
>>  as this as bugs -- that very basic quality assurance (TQM) would 
>> find such flaws (which are actually design errors) before the 
>> product is kicked out the door.
> 
> Oh, they use it.  It's just that we're seeing the "live" development 
> process in progress, before a normal product (freedomware or not) 
> would under normal conditions be claimed to be ready for ordinary 
> people.
> 
This would be acceptable in TRUNK or a development branch, but not in
the release branch.

> Now I 100% support the oft-repeated freedomware mantra, release 
> early, release often, and kde CANNOT be faulted for that!

I do fault them for that.  The current quality assurance process sucks.

> (In fact, they've done an exceedingly good job in that regard!)  What
>  they /can/ be faulted for, and what I /do/ fault them for, is 
> claiming the current state is release quality, appropriate for the 
> ordinary user to install and use in the course of ordinary daily 
> business mission-critical work.

Agreed.  Release early and often but I think that those that write code
should have the personal responsibility to do some basic TQM on their
own work (I do).

> It's getting close, but as you say and as I've repeated as well, this
>  sort of bug shouldn't be present (at least not in quantity) in 
> something deemed to be release quality, as kde4 has been claimed to 
> be since 4.2, way before it even improved to /this/ state.
> 
Actually, this is more egregious since it appears to be a design error.
  One of my instructors in engineering college had a bromide that he
borrowed from carpentry: 'Design twice and code once'.

>> Some of these issues should have been caught before anything was 
>> ever released (or even committed to the repository).
> 
> I'll disagree with that.  The repo commit is simply the result of an 
> international team of people with widely differing native languages 
> and cultures and thus reasonably differing interpretations of API 
> documentation and etc, working on the same project, committing 
> "'round the clock" as the saying goes.  Keep in mind it's a volunteer
>  team, and paid developer policies such as buddy review of every bit 
> of code before commit simply don't work in the freedomware world.

I am saying that people should review their own work.  I think that
people will find what enterprises (not including MicroSoft :-D) have
found, which is that preventing defects from the start takes much less
time in the long run than finding and fixing them later.

> It'd slow development to a stand-still, and wring sufficient joy out 
> of the process that people would quickly find other tasks taking the 
> time they had been volunteering on kde (or almost any other 
> freedomware project you happen to be looking at).
> 
I learned software *engineering* in college.  I know no other way but to
make sure that the code that I write works before it leaves my machine.
  People must be responsible to see that their code works.  What we have
now is that people write code, don't even check to see that it compiles,
commits it, and they wait for bug reports to see if it works.  I
exaggerate to make my point.  Basically, you are saying that unless
developers can be sloppy, that they will not continue to work for the
project.  Well I do not find that acceptable.  Excellence requires that
people take pride in their work.  People that take pride in their work
will not do sloppy work -- it really is that simple.

> The attitude, and I believe it's correct, is either don't break the 
> tree or where it needs breaking, do so with a commitment to help 
> fixing it back to working condition.  But for individual devs 
> particularly on non- core projects such as kget and konqueror 
> add-ons, there's a reasonably liberal view on what can be committed, 
> with the attitude favoring getting the code in there and working, 
> where others can work on it later if necessary.  And I believe that's
>  the CORRECT attitude, commit-wise!
> 
That is not a good software engineering methodology.  But, you are not
totally wrong.  Yes, if you are working on a block of code and working
on that code breaks other things, yes that should be committed to TRUNK
as long as everything still compiles.  But, to partially do a job in the
hopes that someone will finish it, is not acceptable.

> Now once the code is committed and the basic functionality working, 
> it's time to polish things.

I have to tell you that it is my belief that hacking is not a good
software engineering methodology.  I have to disagree with you here.  If
you commit something with design defects, it isn't about polishing
things.  Parts of the code will then have to be redone.

> That's where we're at in this regard, here. Thus, we get to 
> "release".  As above, I'm 100% behind the freedomware mantra "release
>  early, release often", and kde CANNOT be rightly faulted in that 
> regard.
> 
The problem is that KDE is not experimental software.  What we have is
what I would call a development branch, which is fine.  The development
branch should release early and often so that more people can test it if
developers aren't willing to test their own work.

> Where they /can/ be faulted, however (and again), is in claiming this
>  stuff's ready for normal use.  At least it's reasonably functional, 
> now, and we're dealing with finish and polish issues.

No, we still have more basic issues.  Things which simply do not work
and these appear to be either design defects or due to a failure to use
the basic development process.

> That's basic rc quality, tho as of the 4.3 series I'd call kde4 as a
>  whole rc quality just yet, but certainly late beta.  Get the code
> out there.

Yes.

> Get it in the hands of as many users willing to test as possible.

Yes.

> Get them reportng bugs.

Yes.

> Just don't call it full release quality yet.

Yes, call it (KDE-4.3.3) KDE4-0.8.3.  Nobody will complain if version 
0.8.3 still has problems.

> That's the only place kde4 has fallen down, IMO.  I've absolutely no 
> issues with the code as it is presented today, provided it's not 
> claimed to be general release quality yet.

If KDE had applied some basic TQM methods, the code would be in better
shape and, believe it or not, developers would have accomplished more
while working less.  That is why enterprises (not software) have adopted
TQM.  It actually does work.  You find the defects at the source and the 
result is better quality and reduced effort.

> That they ARE making that claim, and what's worse, that they were
> making it with 4.2, simply stretches their credibility beyond the
> breaking point. How now are they to be trusted in any /other/ claims
> they make?  Of course the other place they've fallen down is in
> pulling support for what actually /was/ release quality by now, the
> kde3 series, and that AFTER making a very public claim that it would
> be supported as long as there were users.  But given that they claim
> kde4 is ready for the masses, and indeed, that it was ready with 4.2,
> when there were still clear issues with broken functionality... given
> that, I suppose the position on ending kde3 support is at least
> understandable.
> 
>> It is becoming obvious that the KDE project is in need of a quality
>>  assurance plan.  The fact that there is a list: "kde-quality" 
>> which had a different purpose and now has almost no traffic speaks 
>> volumes.  Basic TQM should catch such rough edges.
> 
> It could be argued that the QA plan is in accord with the "release 
> early, release often" mantra of freedomware, that they are doing just
>  that, and relying on their faithful beta testers to report the 
> issues so they can be fixed.  I haven't a problem with that at all...
>  as long as there's some sort of truth in labeling, the bit that 
> seems to be missing, in this case.
> 
Perhaps the Beta testers haven't done their job, or perhaps the bugs 
reported haven't been promptly fixed.  Either way, the system hasn't 
produced a product with adequate quality.  If KDE is going to regain its 
damaged reputation, quality must be improved.  To do that, methodologies 
must be improved.

-- 
James Tyrer

Linux (mostly) From Scratch
___________________________________________________
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.