>I'd use the "Search by People" section. The first of the three >groups
The problem is, in the final step (atm I'm just tinkering) I want to exclude more than three assignees from the search. some of the assignees I'd like to exclude: openoffice ooo "AOO security list" issues secur...@openoffice.apache.org >If you use the advanced search options then you need to select >"matches regular expression" rather than "is equal to". Using ^ooo$ and "matches regular expression" does not work for me. Can you tell what "is equal to" can be used for? (only int, double, ...?) >you will end up owing Scotch to Apache Infra admins for the >extra >work they have to do to clean up the mess ;-) I see. thx On 26.09.2013 at 11:47 PM, "Rob Weir" <robw...@apache.org> wrote: > >On Thu, Sep 26, 2013 at 4:50 PM, <bugreporte...@hushmail.com> >wrote: >>>> You can use the criterion "Time Since Assignee Touched" "is >>>>greater than" >> Did not see that thanks. >> >>>Back in July I reset the assignment for all issues that had not >>>changed in more than 2000 days. >> >> Today is September 26, 2013 so that means that 2000 days before >today would be April 5, 2008. [1] >> Can you please tell me why the assignee of the issue >https://issues.apache.org/ooo/show_bug.cgi?id=20525 was not reset? >> Cause when looking at the History there is nothing after 2004-06- >17 15:00:01 UTC (besides a comment on 2007-05-03 12:24:50 UTC ). >> > >I used the "time since assignee touched" field. It looks like in >this >case the assignee changed his email address. I don't know if that >impacted the query strategy. But you can find all the issues that >I >did reset by searching for the comment string "Reset assignee on >issues not touched by assignee in more than 2000 days." > >> Can you please tell me how to find bugs of a certain assignee? >> I want to get all bugs listed which are from the assignee ooo . >> When (in the Advanced Search) I select "Assignee" in "Custom >Search" and choose "is equal to" and then set >> the value to ooo it does not work. Using "is equal to any of the >strings" instead of "is equal to" does >> not work as well -> ????? >> > >I'd use the "Search by People" section. The first of the three >groups >there is already set up to search for assignee. One of the search >options is for "contains", so you can then just enter "ooo". > >> Trying to use regular expression and typing ^ooo$ does also not >work. (^ooo works but then I get also things like ooo*) >> > >If you use the advanced search options then you need to select >"matches regular expression" rather than "is equal to". > >>>We all know who is active and who isn't. >> Did not know that. >> >>>Notifications are all-or-nothing. A BZ admin can disable all >>>notifications, run a batch operation, and then re-enable >>>notifications. But we have no easy way to notify only assignees. >> >> What would happen if you leave the notification enabled and then >reset all the assignee fields? >> > >It would not be pretty. It would trigger notifications to be >emailed >to the old assignee, but also everyone that commented on the issue >previously, or added themselves to cc. So a rough guess, for N >old >issues you would generate 4x email notifications. Doing this for >a >handful, 10 or 20 issues is fine. But not for thousands. If you >do >this you will end up owing Scotch to Apache Infra admins for the >extra >work they have to do to clean up the mess ;-) > >Regards, > >-Rob > > >> thx >> >> [1]http://www.convertunits.com/dates/daysfromnow/-2000 >> >> On 26.09.2013 at 3:39 PM, "Rob Weir" <robw...@apache.org> wrote: >>> >>>On Wed, Sep 25, 2013 at 8:41 AM, Regina Henschel >>><rb.hensc...@t-online.de> wrote: >>>> Hi, >>>> >>>> bugreporte...@hushmail.com schrieb: >>>> >>>>> Stop! Don't invoke the bugzilla guru. >>>>> Looks like I made it. Will invastigate farther. >>>>> That's what I use now: >>>>> http://img18.imageshack.us/i/vk57.png/ >>>>> >>>>> Are there other assignees we should exclude? >>>>> >>>> >>>> You can use the criterion "Time Since Assignee Touched" "is >>>greater than" >>>> "900d". >>>> >>>> Exclude assignee secur...@openoffice.apache.org from search. >>>> >>>> Have you count, how many issues are affected? For example, with >>>>900d I get >>>> 322 bugs. With >360d and restriction to 99000<BugID <= 100000 I >>>get 70 bugs, >>>> which is 7%. So expand to more than 120000 issues gives perhaps >>>about 8000 >>>> matches. Other complex queries I have tried need so long, that >I >>>have not >>>> wait. I guess, that a direct SQL search in the data base can >use >>>more >>>> efficient search statements than using the UI. >>>> >>>> I like, that former, inactive assignees are reset to the new >>>default. But >>>> such bulk change needs, that the general notifications are >>>suppressed. I >>>> don't know, whether it is possible to only inform the >assignees. >>>So please >>>> wait till it is morning for Rob and he has a change to read >this. >>>> >>> >>>Notifications are all-or-nothing. A BZ admin can disable all >>>notifications, run a batch operation, and then re-enable >>>notifications. But we have no easy way to notify only assignees. >>> >>>Back in July I reset the assignment for all issues that had not >>>changed in more than 2000 days. 543 issues were reset in that >>>action. I've also done other resets for issues assigned to >defunct >>>openoffice.org, novell.com, sun.com and oracle.com email >addresses. >>> >>>There may be others that could be reset as well, but I'm not sure >>>it >>>really helps anything. As a practical matter, no active >developer >>>will avoid fixing an issue just because it is assigned to someone >>>else >>>who is not longer active. We all know who is active and who >isn't. >>>And even if we did reset everything to the default, and only had >>>currently active developers make self-assignments, this >information >>>would be out of date again within a year. Unless someone wants >to >>>monitor and remind developers and testers on an ongoing basis, >the >>>database reverts to its natural chaotic state. >>> >>>Things that need constant reminding: >>> >>>1) Unconfirmed issues need to be tested and either confirmed or >>>closed >>> >>>2) Unconfirmed issues where we are waiting for more information >>>from >>>the user -- if the user does not respond we need to close the >issue >>> >>>3) Issues that are targetted to be fixed in a given release but >are >>>not -- these need to have their target set back to the default >>> >>>4) Issues that are marked as fixed in a release need to be tested >>>and >>>marked as resolved if they are actually fixed. >>> >>>As a BZ Admin I can help get us to a "clean slate" on some of >these >>>items, but we really need someone (or a group of volunteers) to >>>take >>>the lead on maintaining the quality of the BZ issues by >>>reminding/nagging the rest of us to keep our issues up to date. >>>There are a lot of report and charting options in BZ, but it >>>requires >>>some knowledge to make the most of them. I'm happy to help get >>>someone started on this if anyone is interested. >>> >>>Regards, >>> >>>-Rob >>> >>>----------------------------------------------------------------- >-- >>>-- >>>To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> >> ----------------------------------------------------------------- >---- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > >------------------------------------------------------------------- >-- >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
