Help KDE: Clean Up bugs.kde.org

As KDE 3.2 is approaching and the first Beta version is near, more and more people are testing it. Therefore, a lot of new bugs are appearing in KDE's bugtracking system. While this is of course a good thing, it is much easier for the developers if all the reported bugs are (still) valid and precise enough. Everyone with a current version of KDE is able to do this cleanup-work, coding-knowledge is not needed. Think of it this way: The less time the developers spend on fixing bug reports, the more time they can spend on fixing the bugs themselves! So if you wish to help KDE, consider reading through this manual posted on the KDE Community Wiki Site and do your part in making KDE 3.2 the best KDE ever!

Dot Categories: 

Comments

by Nobody (not verified)

Could KDE integrate some sort of grid computing software for people willing to donate extra CPU cycles for for example source compiling rounds?

Using similar techs as distributed.net, seti@home, folding@home, XTremWeb, ssic-linux and similar interface should not be a big software R&D deal by using software like mpich2 with distcc variation?!?

Oh well, just a thought (perhaps for the kde-4.0 release cycle). ;-)

by Mark Hannessen (not verified)

you can have mine too.

an AMD XP2200 with ( very soon ) 40 kbps up and 100 kbps down sitting on his ass with 95% cpu idle.

by Spy Hunter (not verified)

Sorry, you can't have mine. XScreensaver uses up all my idle CPU time ;-)

JWZ just came out with some cool new hacks too! XScreensaver is great.

by Chris Howells (not verified)

While at developer conferences Troll Tech's Teambuilder is invariably used, at other times unfortunately the lack of bandwidth (the Teambuilder documentation suggests that 10Mbit ethernet may struggle) and latency would more then likely slow down complilation rather than speed it up.

I agree, but only because teambuilder&ccdist are too primitive: if they would combine distributed caching of compiled executables (not .o files, but the whole libraries and programs) with a way to analyse all input (compiler options, checksums of all used sources, header and libraries) it would work. Simply because libkdecore looks the same on all Suse 9.0 installations, as long as the sources don't change and people are using the same options.
But this is no possible with make...

by Ingo Klöcker (not verified)

Obviously the source code changes if developers work on the code so your suggestion doesn't make much sense, does it?

by Alex (not verified)

I will close as amny as I know that are no longer vallid for 3.1, but I don't have a way to run head.

I have SuSE 8.2. I guess I could try Gentoo though.

by Anonymous (not verified)

Close them if they are reported for an older version than 3.1.x. It's unlikely that the same error will show up again in 3.2.

> but I don't have a way to run head.

/me thinks beta1 might be packaged..

If you don't want to wait for Beta1 ( I suggest you don't), get konstruct-unstable and with a little tweaking, you'd be building from HEAD in no time.

by Anonymous (not verified)

With daily snapshot tarballs? That requires some bunch of tweaking/manual interaction.

With `cvs up`. and not that much tweaking.
in gar.lib.mk, after configure-%/configure I added:
@pushd $* && cvs -q up -d -rHEAD && make -f Makefile.cvs && popd

ugly, crufy and convulated ? I guess - but it works. if you want a new CVS snapshot you simply remove your cookies and rebuild.

by Alex (not verified)

I want to maybe run gentoo on a system to test KDE 3.2's bugs

How hard do you think taht is and how many hours should it take on a 2 ghz system?

by Rayiner Hashem (not verified)

I run KDE 3.2 CVS on Gentoo. On a 2GHz P4, ccache'd builds of kdelibs and kdebase take a couple of hours. Usually, I compile overnight, and all the major bits (network, PIM, utils) finish in that time. One thing to remember, however, is that some packages may not compile. So you don't want to do "emerge kde" because that way, if kdenetwork fails to compile, nothing afterwards will be compiled. What you want to do is do "emerge arts ; emerge kdelibs; emerge kdebase; ..." seperately.

by anon (not verified)

One thing to mention is that gentoo's portage handles distcc and ccache automatically if installed. The CVS ebuilds are available from http://dev.gentoo.org/~caleb/kde-cvs.html .. maintained by Caleb Tennis of kdevelop fame. They work like magic.

by chris (not verified)

How is this ? :

- install ab debian from knoppix
- use Orth's Debs zu use KDE-CVS

should only take 1 hour or so , depends on your
line speed.

greetings chris.

by Marcus Whitney (not verified)

Has anyone else had an issue trying to emerge kdenetwork 3.2.0 beta on Gentoo? Mine fails during the install when approaching the kwireless stuff. It is an upgrade from 3.2.0 alpha.

SuSE users can find snapshot rpms here, sometimes the directory contains only some rpms, if the build failed, but it changes every day:

ftp://ftp.suse.com/pub/people/adrian/

by James Richard Tyrer (not verified)

I have tried some bug busting, but I am not sure of the proper criteria.

I was closing them if I couldn't confirm them on the current STABLE branch release from CVS. Is this OK?

I think that we must consider dumping some of the old bugs. Should bugs for the 2.x.y branch that are over a year old just be purged from the system with a message sent to the reporter that if the problem still exists on 3.x.y that thsy should write a new report.

Also, what happens to the bug reports on HEAD when the first Beta of the new branch is tagged? Haven't they become irrelevant to some extent.

--
JRT

> I was closing them if I couldn't confirm them on the current STABLE branch release from CVS. Is this OK?

If the report was not filed against HEAD/newer version it should be fine of course.

> what happens to the bug reports on HEAD when the first Beta of the new branch is tagged? Haven't they become irrelevant to some extent.

Not irrelevant, bugs don't disappear just because HEAD was tagged. A tag is just a label, no branch. There will be no new branch (then stable KDE_3_2_BRANCH) until after the KDE 3.2 release.

by James Richard Tyrer (not verified)

The question is:

> What happens to the bug reports on HEAD when the first Beta of the new branch is tagged?

While you may have a point that this time point in question is when the KDE_3_2_BRANCH is added, it doesn't anwswer the question of what should be done with them.

The question is whether development is being done on HEAD that is not part of the 3.2 BETA. If that has happened then the branches have diverged and it is time for the "QA department" to do something with the bug reports for HEAD.

These bug reports need to diverge as well. The ones that are fixed in HEAD prior to the divengence should be reduced to a list for regression testing and the ones that are not fixed should be updated for the current HEAD.

Perhaps there needs to be a way to tag the bugs as well.

NOTE: If you have better ideas about how to deal with this mountain of bugs, please post them!

--
JRT

by Nicolas Goutte (not verified)

There is no regresion testing done with the bug database.

Bugs marked as RESOLVED will be definitively closed when KDE 3.2 is out. That is how Bugzilla works. (Well with Bugzilla, normally you are supposed to have a QA team to mark them as VERFIED, but we have not any QA team, so no VERIFIED status in KDE.)

And again: the branch is only created *shortly* (hours, days) before KDE 3.2 is released.

Have a nice day!

There aren't enough 2.x bugs in our database to even argue about them.
There are many more for 3.0 and 3.1 and many of them are still valid.

by James Richard Tyrer (not verified)

The question remains, should the fact that a bug is for 2.x.y be sufficent reason for closing it and asking the reporter to resubmit it if it is still a problem in 3.1.4?

--
JRT

by Ingo Klöcker (not verified)

If you can't reproduce a 2.x.y bug with 3.1.4 or later then close it (as WORKSFORME) and ask the reporter to re-open it in case he can still reproduce the problem with 3.1.4 or later.

by Nicolas Goutte (not verified)

If the bug can be reproduced, it remains valid.

If you can add new data from never version for the bug, that is fine too.

However, if you have such a bug, that you cannot reproduce him, that someone asked the reporter a question and that the reporter has *not* answered for many months (6 being the thumb rule), then you can mark the bug as RESOLVED/INVALID.

Have a nice day!

by Badri Pillai (not verified)

Hi all,

Just now I started konstruct (cd meta/everything 8-) on LFS 4.x based system.

Soon you may hear from me too!!.

Until then,

Badri

by Anonymous (not verified)

Not a good day to do so because "the first Beta version is near".

by Anonymous (not verified)

And what is completely missing in there, check your own bug reports after an update to a newer version! Nobody can better tell if the same bug still occurs for the original reporter than himself.

by ferdinand (not verified)

Hi!
IMHO the bug reporter s the most competent one to judge if a bug is resolved.

So it would be a good idea to send a list of open bugs to the reporter to ask/confirm if the bug has been resolved. Some intelligence could be used to mark the bug as solved if the reporter just clicks a link in it's mail without urging him to open an account.

Since bugs.kde.org is using bugzilla all reporters actually need to have an account already to be able to write a bug/wish report at all. So all one need to do to contact a reporter is commenting to a bug/wish report, the reporter should get the respective message as email (unless s/he changed the address meanwhile). So the best thing you can do is picking an old bug you can't reproduce and add a message to it asking the report to close it.

Sadly in many cases the reporter doesn't answer so you'll need someone else to close it (eg. contact me at datschge at gmx de). Also there are old reports which were created when bugs.kde.org didn't use bugzilla yet (about 2900 right now, see http://tinyurl.com/ss8q) so those reporter might not have an account yet.

An effective way of searching for old reports which are probably resolved in KDE already is searching for reports which didn't have any kind of activity (no new messages, no votes, no changes of any kind) for a very long time. For example http://tinyurl.com/ssfe is a list of currently about 1600 reports which weren't touched at all since one year ago.

by Anonymous (not verified)

> http://tinyurl.com/ssfe is a list of currently about 1600 reports which weren't touched at all since one year ago.

Of which "only" 359 are bug reports and the rest wishes which likely nobody other than the reporter needs.

That's a great reason to keep them in the database, not?

by Nicolas Goutte (not verified)

No new message does not mean that the bug is fixed. For example many bugs for KWord are still valid but have not had messages for months.

It is another case when a question was asked to the reporter and that many months later, there is not any answer. Such bugs should be marked as RESOLVED/INVALID. (If you have not enough rights to do that, just add a message proposing to mark the bug as RESOLVED/INVALID. It would give the reporter a last change to answer.)

Have a nice day!

by Anonymous (not verified)

Better WONTFIX (because of missing information).

by Nicolas Goutte (not verified)

No, the report is invalid, as you cannot work with it.

WONTFIX would be when you understood the report (even with very few data) but do not want to change anything.

An example for WONTFIX: the file from application XYZ cannot be read. The user has not attached the document but the developer knows that XYZ produces buggy files anyway, so he do not care.

Have a nice day!

by cbcbcb (not verified)

does anyone else see funny link behaviour when hovering over links in Konqueror CVS at the moment:
http://www.drobe.co.uk/ and http://news.bbc.co.uk/ exhibit this behaviour.

by Mike (not verified)

Would someone please fix bug #39693. Its been around for ages and its one of the most annoying.

by Markus (not verified)

I support this suggestion strongly! :)

by Alex (not verified)

O'Reilly is working with COMDEX to organize an Open Source Innovation Area on the COMDEX Exhibit Floor. They nominated 21 projects and they'd like you to help them select the six projects they'll send to COMDEX. The winning projects will be recognized by COMDEX and they'll invite a leader from the project to come to COMDEX and run demos on the show floor. This will give Open Source projects an opportunity to go where only commercial software vendors have gone before.

Vote for the projects you think are most essential to OSS
http://www.oreillynet.com/contest/comdex/

Here are the current standings:

1. php MyAdmin (2793)
2. Eclipse (252)
3. TightVNC (216)
4. Plone (65)
5. MPlayer 39
6. OpenOffice.org (19)
6. GNOME (19)
6. KDE (19)

Very suprising, I expected KDE and GNOME to be at the forefront of the race, not lagging in last place.

Be sure to vote for the projects most essential to OSS, the contest will end soon.

KDE ALL THE WAY!!! =) =) =)
I would love to see a beta of KDE 3.2 demonstrated at COMDEX. From now on, I will vote every day KDE and only KDE so that KDE can actually get ahead. If I vote for OO.org, KDE, and GNOME it is as if I haven't voted at all, because their all getting the same benefit.

by anon (not verified)

Wow, that must be messed up or something. I've personally voted for KDE about ten times in the last ten days.

by Anonymous (not verified)

> Here are the current standings: 6. KDE (19)

You're referring to http://www.osdir.com/Downloads-req-viewdownloaddetails-lid-124-ttitle-KD...? The voting (or better rating) of the linked download directory entries has nothing to do with the COMDEX context.

by Onno (not verified)

In the links for HELP KDE: Clean Up Bugs.kde.org... I cannot view the manual
http://kde.ground.cz/tiki-index.php?page=Bug+Triage

It states I don't have acces

by BoodOk (not verified)

I have same problem. Maybe the concern overloaded server capacity :-)

by Datschge (not verified)

The server seems to be misconfigured right now. http://tinyurl.com/svdg is a link to a google cache of the Bug Triage page.

by Alex (not verified)

Does it matter if I am using 2.4 or 2.6 test KDE to verify bugs?

by anon (not verified)

nope, kde isn't linux dependant anyways =)

by Nicolas Goutte (not verified)

No, except if the bug might be due to Linux's behaviour.

Have a nice day!