Bug reporting for KDE 4

[Dirk Mueller]

On Monday 29 October 2007, Andreas Hartmetz wrote:

> -A more structured front page (Don't have multiple columns, and don't align
> them to the left and right screen borders).

Okay. The idea behind was that it fits on one screen size. There might be 
better layouts possible, but its just html (trunk/bugs/). Please, can you 
send me a version of the page that you like?

> -The new KDE design

Thats actually partly done thanks to Rainer Endres. I'll wrap it up as soon as 
I have time. it is actually under bugsnew.kde.org but its not viewable right 
now, as the last database import failed.

> -A bug list view that doesn't abbreviate column descriptions (wtf?!)

There is a "wtf" column? Which column's abbreviation do you dislike? "ID" ?

> -The search mask is probably the worst part. A search line for every list
> box with more than 10 items would be a start.

the only list box that has more than 10 items is the "product" one. I agree 
that a search would probably help a lot. It is not a complicated job for 
anyone knowing HTML and javascript. The alternative would be to put more love 
into kbugbuster. Noone would be offended if we'd have a really good KDE GUI 
frontend for handling our bugs ;)

> -Purge old stuff from the search mask, like all entries for versions before
> 3.2 or so in the "Version" list box. This thing looks like a dumpster.

you can't. As long as there is a bug that was filed against this version 
number (and there is, otherwise the version number wouldn't be there), you 
can't purge the version number.

But on the other side, many people do not really use the version field, even 
if they could. Just randomly from my inbox today, most of the reports 
are "unspecified" version. I think we can improve on that. 

> "cvs", "CVS", "CVS HEAD", "subversion", "Subversion", "SVN", "SVN (KDE3
> branch)", "SVN trunk", "svn trunk", "SVN trunk (KDE4
> version)", "svn-trunk", "trunk". ?!?!?!

where do you see that? which products have them assigned? I can fix that 
trivially (anyone else with product editing rights) can do so too. The 
versions can be renamed and then they will be unified in the query if they're 
identical. Not a reason to dump the existing bugzilla and start with 
something new - more a reason to give it some attention. It's an excellent 
tool if everyone uses it. Its just a heavy piece of metal if noone does. 

> The "Component" box is not much better.

did you notice that the listing shortens once you select one or more products?

> -I don't understand what "Bugs.KDE.Org Actions" is doing at the bottom of
> the page - or what it's good for. It probably shouldn't be there, or it
> should be at the top.

it is at the top (in the blue header). In addition you can define custom 
queries and they will appear as a link there for you. 

> > I don`t think its a good idea to invent yet-another-way of trackign bugs.
> > KDE 4 bugs are no different than KDE 3 bugs, and a mailing list is an
> > medium without memory. Use a tracker.
> Mailing lists certainly have enough memory for a temporary beta bugs list.
> KMail stores mails just fine, and its search is an order of magnitude
> faster and easier to use than bugzilla's.

You can have that already now: kde-bugs-dist at kde.org 
(http://lists.kde.org/?l=kde-bugs-dist). Besides that, I disagree. The only 
thing you could search for is the subject to be fast. All the other stuff is 
not really indexed either. 

a) Try searching for bugs that are assigned to thiago at kde.org, that are still 
open and where he hasn't looked at (commented on or took an action) for more 
than 14 days. 

b) Try searching for a crash that was reported against kmail in the last week 
and that has something to do with imap. 

If you can do that with your kmail, then your kmail is vastly different from 
mine and I want to download it. Otherwise, please tell me the time it took 
you to figure out the buglist. 

The answer for a) is 21 bugs (took me about 19s) and the answer for b) is one 
(took me 7s to fill out the form and have the server respond to me). Please 
let me know your timings for your kmail search. 

> I realize that there probably is no good bug tracker for really large
> projects :(. Bugzilla being written in Perl is a big reason for me not to
> touch it.

Thats unfortunate, because you don't have to touch perl at all. Bugzilla uses 
clean separation. all the "GUI" stuff you talked about is plain HTML + 
Javascript (its the so called "Template toolkit"). You don't have to learn a 
single line of perl to be able to modify it and fix all the bugs you reported 
above. 

Yes, you'd have to learn HTML though, but thats the same with mantis, 
launchpad or anything else that was suggested as a new bug tracker and that 
we'd want to customize just a tiny little bit. 


Greetings,
Dirk