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
