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
