kde bugzilla ui changes: feedback wanted
If you've been reading the kde-core-devel mailing list, there's been some talk recently about bugzilla, how much it sucks, whether we should switch, and alternative tools to switch to. However, only one person told me about something that could be improved. So, in order to get feedback on whether or not our customizations that are currently live on bugs.kde.org are hindering vs. helping, I've changed the layout on bugstest.kde.org back to the standard default bugzilla layout.
Please, if you use kde's bugzilla currently, take some time to test out bugstest.kde.org. When you do this, please send feedback. The feedback should be something that we're doing on the live site that is done better by the test site. It can be good or bad!This can be in the form of a bug report in bugs.kde.org against the bugs.kde.org product, or sending me a simple email. Please include changes that you want made, or specific issues with the site so that I can at least look at fixing them.
I get that a lot of KDE folks are not happy with our current Bugzilla. I'm glad that you want to have good tools to work with. So far, I haven't really seen anything that's better. I've only seen systems that do things differently, which means that we can emulate that with Bugzilla, most likely. That's after using Jira, Mantis, Flyspray, Bugzilla, and Redmine, and an old version of RT. Why not work on improving our current tool? If you think that Bugzilla has fundamental problems that require switching, I want to know what those are too.
November 19th, 2009 - 12:50
I think one of the reasons people are not happy with KDE’s Bugzilla is the fact that nobody seem to care about fixing the bugs reported there.
November 19th, 2009 - 12:52
I still think that bugzilla is not the main problem. We need more devs and triagers at first… Anyway, if we have to found something about bugzilla, I could say that a system to reduce duplicates could be helpful… but I really don’t know if other tools could help or how to modify bugzilla…
I’ll give a try to the demo
bye!
November 19th, 2009 - 13:02
So I just played a little bit with the test installation. What I really like compared to bugs.kde.org is that the “mark as duplicate” is at the top of the page. It’s so often that I see bugbot reporting a new bug on IRC and I think “dup” and just want to enter the number. But that might be special to kwin as we have a high duplicate bug rate. So for others it might be better to have it below the comment section.
Another issue which is perhaps better in the test installation: when I reassign a bug to e.g. plasma I have to change the component then scroll down to the assignee section and click on edit and reset assignee to default. In the test installation it’s in one section so I don’t need to scroll and I think that lowers the risk that it is forgotten. (Happens quite often that component is changed to kwin, but the assignee is not changed so not email on the mailinglist and no notification)
November 19th, 2009 - 13:20
I tried the test in rekonq. It’s cleaner, and certainly the package list makes things easier, but I did find a couple of problems. I am using Fedora packages, which it said were unlisted binaries. The Component and Version sections were just black patches. I have a screenshot of that part of the window if you’d like to see it.
November 19th, 2009 - 13:33
- autoreminder to reporter, asking if bug still exists in new version
- would be nice if bugs/wishes could be tied to the development schedule http://techbase.kde.org/Schedules , so that a user knows that a bug is targeted for KDE 4.4, 4.4.1, 4,5…. or as “unknown”
This would make development more transparent. Could help to find people who adopt them or let users “lobby” for there bugs. Crashes should be automatically tied to the next release, so that developers have it easier to get an overview and they get a higher priority.
- It should be possible to report another bug/ wish to the same component/programe after reporting a bug / wish.
- it should be possible to ad an attachment to the initial report.
- There should be the possibility to confirm a bug exits still in the actual version. At the moment it is only possible in the text, but I believe it may be more useful to have this automated, so that they can be searched for. Bugs which are confirmed are more likely to still exit and still bother users.
November 19th, 2009 - 13:39
Some feedback (hope it’s OK here as well):
1) it’s much easier / faster to report a bug on the plain bugzilla installation. I _hate_ the “wizard” on bugs.kde.org, it slows down. The plain one from bugzilla just gets down to the game, doesn’t get into your way. Select a product and than file in the missing stuff. Much better!
Maybe this is not “good” for the first-time bug-reporters, but it’s lightyears faster for “advanced” bug reporters, or developers like me that use bugzilla also for bugs they find (and want to fix eventually).
2) Of course somewhere we need a check for duplicates, but imo this requires a better search form than currently available: I rarely (and others neither) find the same keywords for a given problem. One should _either_ insert keywords _or_ a backtrace. Searching the backtrace for duplicates would imo be much better and saves Dario some time. searching keywords should be optional but required for wishlists and enhancements.
November 20th, 2009 - 02:18
The new layout is so much better that I would love it if the real bugzilla switched to it today.
November 20th, 2009 - 03:06
Slightly off topic, I think one big problem is that the site is slow and thus searching becomes frustrating.
For that reason I started a Qt client that uses bugs.kde.org APIs and stores the bugs locally to search much more intelligently.
So for anyone doing triaging, having this app running will likely be a big help too; http://gitorious.org/bugsviewer
November 20th, 2009 - 10:45
I’d prefer the comment reply text field after the comments.
November 21st, 2009 - 04:20
I can second what Milian Wolff says.
- I skip the wizard by using the “report bug” menu item.
The current wizard makes me type redundant input. E.g. I selected I used SuSE, next it asks how I got my packages, format they are, and whether I’m using Linux/Windows/MacOS as OS. Especially the last question is just annoying.
With the report feature, Bugzilla asks whether the app+version are correct. Once you uncheck the version number, you also need to specify which app this is about, etc..
- Searching for duplicates does not work.
I report a plasma crash, and bugzilla also shows wishes for plasma features.. I report an Akonadi problem, and bugzilla suggests bug reports about Kate too. (imaginary example, but silly things like these do happen).
So I report the bug, spend time writing an explaination, and next there is a developer to close it as DUPLICATE. I rather would have figured that out myself already
With these things fixed, I think bugzilla could – at least for users – get a lot better already. I don’t think the software is really that bad at all, but could need some polishing.
November 21st, 2009 - 15:53
My main issues:
1) Speed! It really is frustrating waiting on bko, but I guess that’s more a hosting issue.
2) Reassigning to a different Product, you have to wait for the next screen to then choose the right Component, couldn’t we do it in one go?
3) When closing as fixed should be able to say what release it was fixed in. That would also need some work in the svn BUG: script, perhaps to automatically assign the next release for the branch the commit was on?
4) Target milestone doesn’t seem to work?
5) In the new layout, could some of the lesser used fields like URL, Keywords, Depends, Blocks be moved to the right?
6) Looks like the layout issues that konqi had with width of bug lists has been fixed?
7) Documentation or flowcharts for the bug lifecycle, how the status is supposed to change, what each value means, etc. We provide absolutely no help to new users or devs to find their way around (or even old ones).
November 24th, 2009 - 03:47
You know, as far as backtrace duplication and analysis goes, I wrote a Bugzilla Extension for bugzilla.gnome.org, called traceparser, that does all sorts of fancy things with stack traces in Bugzilla, including automatically finding identical and similar traces (even when filing a bug). It doesn’t work in Bugzilla 3.4 without modification, but once Bugzilla 3.6 comes out, I could probably make it work pretty nicely if you guys wanted to use it on bugs.kde.org.
Why does bugs.kde.org run under mod_cgi, by the way? That’s the speed problem, for sure.
-Max