On Wed, Oct 10, 2012 at 10:41 AM, Diego Elio Pettenò <flamee...@flameeyes.eu> wrote: > Sure. Preferences are great. Until said preferences mean that bugs that > _are_ 100% valid get closed, repeatedly, without being looked at.
I can't speak to the specifics of whatever the elephant in the room is, but keep in mind that when you have 100 developers on a project there is only so much you can tailor things to individual preferences. I've gotten tinderbox bugs that are upstream issues that I personally accept as valid but which I'll probably never be able to influence upstream to change. I just read them, appreciate them, and then leave them open in the hope that I'll be bored one weekend and find some way to fix it. Usually I find Diego's bugs to be helpfully worded both with helpful logs and background info which saves me having to explore some arcane linking issue. If the result of a tinderbox run is we get 500 bugs that are legit, 3 false positives that waste somebody's time, and 5 legit but debate-ably unimportant bugs that particular maintainers don't want to look at, I'd say we came out ahead. This could be a culture thing. At work I tend to work with large regulated applications that often have hundreds of open bugs at any time - some for years with no intention whatsoever to actually close them. Bug lists aren't really used like worklists in this context, except for the few times a year everybody sits down and prioritizes the list and figures out what is worth fixing, if anything. So, having a few open bugs assigned to me doesn't really bother me. Maybe the solution is some kind of maintainer priority field for personal productivity which is to be set by maintainers only and can be filtered on if a maintainer just doesn't like seeing things in their daily view. Rich
