>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.
I was trying to use ^ as a beginning of a string and $ as the end of a string. To tell BZ that I just want ooo and nothing else like os_ooo. >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 The problem here is that os_ooo, mst.ooo and wuyan.ooorg are also excluded but I only want to exclude ooo (besides the other like openoffice...). >It depends on the field type. But in most cases, such as with the >assignee field, it is a string comparison. So why does it not work when I just use ooo as the value? I also tried using "ooo" and 'ooo' but that did not work either. Is there a special way to tell BZ that ooo is a string, that I might have missed? thx On 27.09.2013 at 4:29 PM, "Rob Weir" <robw...@apache.org> wrote: > >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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
