On Wed, April 30, 2008 13:41, Gerhard Brauer wrote: > It's not - more - an issue for me, I've learned my lesson ;-) (That is, > was Xavier mentioned in his answer). But i know 3 other tasks were the > user must be pointed: Look directly to #12345, the problem you ask about > is already fixed (and closed). I don't see any reason why anybody would actually *search* for bugs that are announced that way. There's a reason for the Task ID being supplied, namely to enable users to enter it directly into that dedicated little search field labeled "Show Task #" fitted snugly into the upper right corner of the flyspray GUI, which leads upon activation directly to the task specified, no matter it's status. However, I'm sorely aware of the problem of not finding closed bugs by default; It's really annoying to be basically forced to always use the enhanced search features. However, as long as the ID is announced, that's simply not an issue. If people who refer to tasks intend to be nice to their readers, though, it's surely a good idea to link the bug id. Saves a couple seconds and prevents typos on the user's side. Either way, deferring bug closure introduces, by definition, an inconsistency between facts and reports. Yeah, that's just a fancy way of saying "Fixed bugs appear as still unfixed". That sucks, because it might entice another developer or *anyone*, for that matter, to look into an issue that is in fact already fixed! To me it does not seem feasible to artificially introduce what could be described as an "intended lack of communication" to circumvent a perceived inability of users to use Flyspray optimally. HELL, NO!!1!eleven RTFM is key, as with all that is Arch. Actually, knowingly introducing inconsistencies into any kind of data storage seems so inherently evil to me that I personally have real trouble reciting good arguments against it! ;) > Regards > Gerhard $POLITE_CLOSURE, Dennis
