How to properly report bugs for KDevelop

September 12, 2009 at 7:29 am | Posted in KDevelop | 2 Comments

Actually this probably applies to any FOSS app out there.

This morning I saw in my irc backlog (lucky you that I keep that and usually at least skim it):

[07:41:33] –> firefly2442_ () has joined #kdevelop
[07:42:29] <firefly2442_> I found a bug in kdevelop 3.5.3, in the project options under run options
[07:42:50] <firefly2442_> I can navigate and specify my main program executable
[07:43:08] <firefly2442_> however, when I try to run it, it doesn’t work because the folders have spaces in them
[07:43:46] <firefly2442_> the actual command that gets executed and run in the bottom window should be modified to add quotes to allow for folders with spaces
[07:43:53] <firefly2442_> should be a simple fix
[07:44:04] <firefly2442_> cheers🙂
[07:44:16] <– firefly2442_ () has quit (Client Quit)

This is a good example of how you should _never_ try to report bugs or problems with KDevelop. Unless of course you just wanted to do a braindump which nobody cares. Its fine to approach us on IRC, but please don’t just dump things and then leave immediately.

The right way of doing this is by either using our bugreporting wizard at KDE Bugzilla or by at least sending a mail to one of our mailing lists so we can reply to you.

I know this is a bit more effort than joining into an irc channel and dropping a few lines, but really there are far better chances of your problem being solved doing the few extra steps.

Sadly this means the above irc-report will not go anywhere, I don’t even have kdevelop3 around anymore, so I cannot test this and file the bug myself. Not to mention that 3.5.3 is rather old (3.5.5 is current) and KDevelop3 is not actively maintained anymore.

2 Comments

  1. You claim that you won’t file the bug nor you have avaliable a testing platform.

    Still, it is a very concise bug that, at the very least you can test on whatever platform you have in, what? two minutes?

    Of course, is good for users to know how to properly feed bugs so they increase the chance of being fixed but taking this very example you look more wanting to ween than to do.

    And as a general matter, you say that “3.5.3 is rather old (3.5.5 is current) and KDevelop3 is not actively maintained anymore.”

    Well, KDevelop on Debian Lenny (current Stable) is 3.5.2 (on KDE 3.5.10). While this is open source and you have no contractual obligation (of course not) it would be good, out of good ethics and professional proud, to support something else than (comically exaggerated) the last version out of HEAD that only compiles on my environment. You could do it “the hard way”, giving support to any version you ever published (after all were it not buggy your support would sum up to zero) or by better engineering practices (clearly stating what’s expected for distributions to be shipped and then supporting at least the last two/three versions, and then seggregating bug fixing from feature additions -for instance, regarding KDE in general, current version is 4.3.1, KDE 4 is still furiously adding new functionality, it still has grave bugs and areas where its functionality is still not on par of that from KDE 3, but then the KDE 3 branch already appears as old and unsopported.

    In the end, you can *ask* and wait for your miriad of users to learn how to properly report a bug but you can *do* better about managing the project you volunteerly jumped in.

    • > You claim that you won’t file the bug nor you have
      > avaliable a testing platform.
      > Still, it is a very concise bug that, at the very least you
      > can test on whatever platform you have in, what? two
      > minutes?

      I could if I had a system that contains KDevelop3. Thats exactly what I said above, I don’t have such a system. In fact there’s only one such system at all that I have access to and when I sit in front of that system I usually have very little time (read need to do work).

      > Well, KDevelop on Debian Lenny (current Stable) is 3.5.2
      > (on KDE 3.5.10)

      Thats the debian maintainers choice, I don’t have any influence on that and the problem here is debians rules on when and how to release. 3.5.3 was released last august, 3.5.4 end of december and both had _very_ little changes (IIRC only bugfixes).

      > it would be good, out of good ethics and professional
      > proud, to support something else than (comically
      > exaggerated) the last version out of HEAD that only
      > compiles on my environment.

      I would if I could, in fact I still use KDevelop3 at work (see above) as its currently impossible to use KDevelop4 for that. However I have no interest in or time to keeping a KDE3 dev-env around on my home machines just for testing a bug every few months.

      I as well as the other KDevelop developers have absolutely no time for that and thats not about managing the project or anything. In fact I already spend serious amounts of time on bugreport-managing.


Sorry, the comment form is closed at this time.

Blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: