Hi, thanks for your quick reply.
On Thu, Jul 09, 2009 at 06:25:24PM -0700, Don Armstrong wrote: > On Thu, 09 Jul 2009, Patrick Schoenfeld wrote: > > currently the BTS does not really provide a sensible way to let us > > display a current list of rc bugs in our different suites. > > Actually, it does. ah, IC what I've done wrong. Still, the filter possibilies are far from beeing sensible. That is because I either must bookmark your URL or use the unintuitive and inefficient way to filter with the formular. IMHO it has the following flaws: - It requires to query the 'database' several times before I get the wanted result - It requires more steps as neccessary on the user side - It is really unintuitive that I have to submit a query in order to set a filter. - I need to spell out the severity grades, which is uncomfortable and errorprone While I agree, that I might have read the instructions on the right side of the filter options, I don't think, that this counts as an excuse for that unintuitiveness. Simple things should be simple, without requiring to study documentation and filtering is - from user perspective - a really simple task. So as a better solution I'd suggest to make at least the severity grades checkboxes. Even better would be if all possible options with more then 1 possible values would be selectable this way. There are other possible ways to solve that, but I guss we want to do without Javascript ;) > testing. [See the select options at the bottom of that page if the URI > scares you.] The URL does not scare me. What scares me, are the select options ;) > > - optional: only those not claimed by someone > > There's no information about this in the BTS, so you can't filter on > it. Hm, its realized as a usertag. Isn't it possible to filter for that? If it isn't, the possibility should eventually be added. As it is really useful to not double efforts. > > - optional: only those which are not yet 'done' (e.g an upload > > fixing this bug has happened) > > This is rather difficult to figure out, unless you mean the trivial > case where someone has -done'd the bug, in which case I suppose I > could add a filter on that. [There's not currently one, but it's > fairly trivial.] I mean that trivial case. If you are neither maintainer of a given package, nor in the role of release team or whatsoever you might be interested in bugs only, which have no solution yet. E.g. those that don't yet have a patch and where no upload happenend. I understand that other groups also want to see bugs, which haven't yet transitioned etc. but I think we should pay due to all groups in Debian that work on RC bugs. Best Regards, Patrick -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
