On Fri, Sep 27, 2013 at 9:39 AM, <bugreporte...@hushmail.com> wrote: >>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. >
What exactly are you looking for? We don't have any user with ID that matches that regular expression, e.g., a line starting with "ooo" followed immediately by a line end. A simpler way to describe this query might be to do an advanced query of: Assignee: (contains none of the strings) openoffice, ooo, issues, AOO security list, secur...@openoffice.apache.org > Can you tell what "is equal to" can be used for? (only int, double, ...?) > It depends on the field type. But in most cases, such as with the assignee field, it is a string comparison. Regards, -Rob >>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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
