On Monday 01 August 2005 02:07, R Hill wrote: > Alec Joseph Warner wrote: > > Donnie Berkholz wrote: > >> > >> Are you having a tough time filtering out enhancements in your queries > >> or something? I don't understand how feature requests could possibly > >> interfere with anything besides other enhancements. > >> > > > > Many of the enhancements aren't marked as such, > > Then they should be. ;) There's nothing wrong with reclassifying your > bugs to make it easier to manage them. The features are there exactly > for this reason - so critical bugs don't get drowned out by less > important bugs or enhancement requests. I guess it doesn't really > matter, but it would have been just as easy to set the severity of these > bugs to min or enh rather than close them, and then they would still > show up on a simple search.
Several people have asked why the available bug attributes don't suffice. The reasons are quite simple: 1) Feature requests won't be addressed any time soon. It was suggested that closing the bugs as LATER will cause more duplicates and effect more work. I deferred (not closed!) 150 feature requests at least a third of which were duplicates. Because feature requests are not being addressed, they are piling up and users are not able to find duplicates with the bugs being open anyway. However, publicizing that feature requests have been put on hold has had the desired affect. There have been no new requests this past week. 2) Every bug change has to be dealt with at least twice. I try to monitor bugs via the emails sent as much as possible. With the amount generated by new feature requests and the numerous "+1" posts on existing requests, it is simply not feasible to parse the incoming mail without making at least two passes. Here, I can hear people suggesting that I just /dev/null the email and monitor bugs via bugzilla. My answer? Opening listing 100+ bugs (that's assuming the bugs were properly categorized (which they are not) - there is actually about 300 bugs open other than the 150 feature requests closed) as well as the bugs is a slow painful process on a 32000bps connection. 3) To be able to utilize bug mails beyond notification. I've written a simple script to create a report of what bugs have changed and how many times within a set period. I'm posting the results to the portage mailing list in order to try and fish out some fresh blood. Having these reports littered with feature requests means that the important stuff that is causing users problems is hidden between all the "oh wouldn't it be lovely" bugs. Yes, this has also been successful already. There's been patches posted on various bugs that actually fix the root cause of the problems outlined. 4) Less user frustration. The two most frequent comments at the moment are "is anybody looking at this?" and "it's been over a year!" Users knowing what's going on and especially finding that their minor bugs are starting to gain some activity can only be a good thing. I could figure out some more reasons if it's really necessary, but the past week has shown that the path chosen (even if there is some better path) is not a bad one as things are working out well thus far. -- Jason Stubbs
pgpcc0nq6l0qk.pgp
Description: PGP signature
