The link[1] in the description of "needs-staging" in the Bugzilla keywords list[3] to is broken as it was recently renamed[2]. [1]: https://wiki.freebsd.org/ports/StageDir [2]: https://wiki.freebsd.org/Ports/StageDir [3]: https://bugs.freebsd.org/bugzilla/describekeywords.cgi
(In reply to Mateusz Piotrowski from comment #0) I've worked around it on the wiki side by using a page redirect. (I learned something new today.)
The needs-staging keyword is deprecated, mostly cause all ports are already staged, and all new ports must be stagedir compliant. I had not removed it earlier are there are other keywords which need to change/remove/be added, and sometimes functionality (auto-assigner) can rely on or use/add keywords in certain cases, and may not resiliently handle their non-presence. I'll work with @gonzo to verify the latter is not the case, and remove it once that has been identified.
In the meantime, I've fixed the description link, added deprecated messaging to it's description, and will delete the redirected page (after seeing if any other pages in the wiki depend on it)
(In reply to Kubilay Kocak from comment #2) Needs staging is not used in auto-assigner, so it's safe to remove it.
(In reply to Oleksandr Tymoshenko from comment #4) Thanks. the auto assignment of keyword:patch based on [tags] in summary has now been removed iirc? Beyond that, are there additions/removals of any keywords in the AA code left at this stage?
Is there anything else we can do here?
Yep, need to test and confirm (needs-qa) whether global keyword removal cascades metadata removal from objects with that keyword.
*hitting upstream again to get confirmation from bugzilla 5.x codebase*
Upstream: justdave | Yes, it does. https://github.com/bugzilla/bugzilla/blob/5.2/Bugzilla/DB/Schema.pm#L600
Still need to confirm either non-use of the patch keyword in the auto-assigner, or if it is still there, have the functionality removed. Removing the keyword without doing that is likely to break the auto-assigner. Its not obvious how the auto-assigner behaves in the non-presence of metadata, fields and values it wants to use to process issues.
The needs-staging keyword has been deleted.
Added keyword: 'crash' to all issues with keyword: 'panic'. The mass issue change took a long time and didn't return/complete, but I have confirmed that all (262) issues now have both keywords. I will remove keyword: 'panic' now.
The panic keyword has been deleted. All issues are now available with keyword: crash
And ugh, mass modifying issues sends out an email to every person that was on an issue that is modified. Note for future keyword 'replacements': its better to delete the keyword via admin, which cascade removes it from all issues, rather than remove it via 'mass change many issues' from a search result. Unfortunately, this is not possible for 'adding' keywords. We need a 'dont send email' extension.
Remove 'et al' from Summary. There's no other deprecated/vestigial keywords that need removal, except patch and patch-ready (see comment 10). The rest of keyword improvements are moving 'component' type keywords to actual components, not in scope for for this issue
See also: bug 198271 > 198271 – Auto-Assigner: IF attachment "is patch" THEN > set maintainer-approval flag value (to + or ?) based on <condition>
Taking a hint from <https://bugzilla.mozilla.org/show_bug.cgi?id=1539302#c7>: > … “Attachment is patch: true” doesn’t work but > “Attachment is patch: 1” does … So, for example … * all open bug reports with a patch, sorted by bug number: <https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open__&f1=attachments.ispatch&list_id=534246&o1=equals&order=Bug+Number&query_format=advanced&v1=1> * all open bug reports with a non-obsolete patch, sorted by assignee: <https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open__&f1=attachments.ispatch&f2=attachments.isobsolete&list_id=534260&o1=equals&o2=equals&order=Assignee&query_format=advanced&v1=1&v2=0> * open bug reports (not in progress) with a non-obsolete patch, sorted by importance, excluding assignments to bugs@⋯, excluding assignments to ports-bugs@⋯, excluding assignments to doc@⋯: <https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=Open&f1=attachments.ispatch&f2=attachments.isobsolete&f3=assigned_to&f4=assigned_to&f5=assigned_to&list_id=534271&o1=equals&o2=equals&o3=notequals&o4=notequals&o5=notequals&order=Importance&query_format=advanced&v1=1&v2=0&v3=bugs%40FreeBSD.org&v4=ports-bugs%40FreeBSD.org&v5=doc%40FreeBSD.org> … and so on. (Hopefully correct; I'll be unable to edit any mistake.)
Until today, I was somehow blind to the 2020-07-11 news item about patches. Oops. (In reply to Graham Perrin ◐ from comment #17) Discussed a few weeks ago in IRC, I was previously unaware of the value/effect of saved searches (their appearance in the footer but not the dashboard, and so on)
Re: bug 268360 comment 3, and comment #10 above I assume that things are not yet (verifiably) ready for removal of the 'patch' keyword …
MARKED AS SPAM
^Triage: take. I just need to ensure that all of these have been deleted.