>> 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 ). 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 -> ????? Trying to use regular expression and typing ^ooo$ does also not work. (^ooo works but then I get also things like ooo*) >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? 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
