There is a proposal on desktop-devel-list to drop bug-buddy reports from either <=GNOME 2.14 or <=GNOME 2.16. I fully agree with <=GNOME 2.14 (receives max 5 bugreports/day). However, not sure about <=GNOME 2.16.
Based on server stats over the last week, we:
- Created 23 GNOME <=2.14 bug-buddy reports. Update: To clarify, the <=2.14 bug-buddy programs updated themselves 9603 times (it does that when you start it and it wasn’t updated for at least 1 day, plus the server config changed). Obviously that method of reporting bugs is so broken that killing it wouldn’t have a big impact.
- Received 5513 XML-RPC GNOME 2.15 + 2.16 bug-buddy reports. I assume 60% are auto-rejected (received!=created).
- Received 475 XML-RPC bug-buddy report for other GNOME versions (sometimes the bug-buddy version couldn’t be determined).
- Created 2405 bugreports in total (over the last 7 days instead of last week).
Seeing above stats, unless I get a good objections from many developers GNOME <=2.14 bug-buddy reports will be dropped (with an explanation message). Before dropping 2.15+2.16, I’d like some (developer) feedback on d-d-l. Please read the entire thread, then add your comments.
RHEL5
There is just one server left to upgrade – menubar. I’m delaying this after GNOME 2.18.1, plus I want to create a test installation first.
Sometimes valid reports are dropped. A dialog with pure XML pops up ;). (Error)
I havent investigated but:
Either size of post (with a full stack trace) or entity
encoding seems to be the problem.
Sorry for the lousy bugreport :(.
Some users might be very annoyed at spending considerable amounts of their time filling out bug report only to have it rejected. Is there anything which can be done to mitigate against this? If nothing else perhaps the warnings messages in future versions of bug-buddy need to be more strongly but carefully warn users of the need to upgrade?
Alan: Did you miss my update about 2.14 and older bug-buddy versions? Those bugreports are mostly lost anyway.
I’m pretty sure I get what you are saying and dropping the old mostly useless reports sounds entirely reasonable. What I am saying is that there will always be a few users who think filing a bug report is a lot of hassle but will do it anyway, unfortunately only later realising the report is not of any use so if you can future proof bug-buddy the client itself and give better warnings at that point rather than just quietly dropping the information at the bugzilla stage.