I would like a FOR_WIKI flag, like we have FOR_ERRATA, FOR_RELEASENOTES And, logically, the complementing IN_WIKI To be used when wiki pages need be created, complemented or or updated. (That are not for errata nor release notes) Because: * Some issues can not be fixed, and should go in wiki * The bug contain valuable information to be documented in wiki etc...
I still think that these keywords such as FOR_* and IN_* should be replaced by flags, as I already suggested in bug 5 some years ago.
Whichever works, but we need *something* working :)
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=5
(In reply to Frédéric "LpSolit" Buclin from comment #1) > I still think that these keywords such as FOR_* and IN_* should be replaced > by flags, as I already suggested in bug 5 some years ago. Can link to a bugs with a flag like with keywords? like https://bugs.mageia.org/buglist.cgi?keywords=FOR_ERRATA9
(In reply to katnatek from comment #3) > Can link to a bugs with a flag like with keywords? like > https://bugs.mageia.org/buglist.cgi?keywords=FOR_ERRATA9 Yes, for instance: https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata7- which is equivalent to: https://bugs.mageia.org/buglist.cgi?f1=flagtypes.name&o1=equals&v1=in_errata7-&resolution=--- But Bugzilla also has a dedicated (built-in) page for flags. For instance: https://bugs.mageia.org/request.cgi?action=queue&type=in_errata7
If you click the "set flags" link at the top right of this bug page, you will see what I have in mind. Flags have 4 states: X = not set (default) ? = requested + = approved/yes/done - = denied/no I see many advantages to flags compared to keywords and the status whiteboard (and based on my 12+ years experience contributing to Bugzilla upstream at Mozilla): - Editing the status whiteboard, e.g. to add MGA9-64-OK or MGA9-32-OK is prone to typos, and you could delete another information in this field by accident. With flags, the name is already set; you just have to set it to ?/+/-. - Another advantage about the mga9-64-ok and mga9-32-ok flags specifically is that each QA member would be free to set the flag to e.g. mga9-64-ok+ or mga9-64-ok- to mean "this fix works for me" or "this fix doesn't work for me" without having to read each comment one by one to know who has tested the fix and what was the result. Here, you would quickly have a summary of the QA process. - Editing keywords to add FOR_ERRATA9 and then edit it to write IN_ERRATA9 is less prone to typos, but you could still remove other keywords by accident, or add IN_ERRATA9 and forget to remove FOR_ERRATA9, which is confusing. With flags, you would set "in_errata9?" to ask for the bug to be listed in the errata, and when this is done, you set the flag to "in_errata9+" to mean that this has been done, or you set the flag to "in_errata9-" to mean that you don't think it should be listed in the errata. Moreover, admins can decide who are allowed to set flags to +/-, e.g. only members of the QA team could set the mga9-64-ok and mga9-32-ok flags. Of course, you can decide that everybody can do it too. This is configurable from this page: https://bugs.mageia.org/editflagtypes.cgi (restricted to admins only). Admins can also decide that such or such flag is only relevant in such or such product/component. For instance, I restricted flags to Infrastructure/Bugzilla only to show you how flags work in Bugzilla without having them in all bugs (yet). Another (IMO big) advantage with flags is that you can request something from a specific person, without having to CC him/her. For instance, I could ask you for some information about this bug, and I set the needinfo flag to "needinfo?<your name or email address here>". You would automatically get an email asking for your attention, and you can also list all requests addressed from/to you from this page: https://bugs.mageia.org/request.cgi?requester=%user%&requestee=%user%&do_union=1&group=type&action=queue which is the "My Requests" link you can see in the page header/footer of every Bugzilla page. At Mozilla, flags are used *A LOT* to track testing and final approvals from admins. I think Mageia should do it too.
Flags: (none) => needinfo?(j.alberto.vc), needinfo?(fri), mga9-64-ok?(marja11), mga9-64-ok?(LpSolit)CC: (none) => fri, marja11
Let's say I successfully tested the fix proposed in this bug, then I set the mga9-64-ok flags to "+". This doesn't override Marja's decision, who can set it to +/- or even cancel the request. I hope I convinced everyone of the many advantages of using flags. ;)
Flags: mga9-64-ok?(LpSolit) => mga9-64-ok+
This is interesting. My head is buzzing with other stuff now but Iĺl diges tmore later. As I see it, we need the decision step (yes/no) to be separate from done. X = not set (default) ? = requested + = approved/yes (decided to be done) - = denied/no * = done (solution approved) (Maybe more suitable English words to be selected by native speaker)
Flags: needinfo?(fri) => (none)
(In reply to Morgan Leijström from comment #7) > As I see it, we need the decision step (yes/no) to be separate from done. These would be separate flags. Flags only have these four X, ?, + and - states. They are hardcoded. You cannot add another state (such as *).
CC: (none) => LpSolit
OK then, quick idea (not much thought) As proposed with small adjustment, bug status: X = not set (default) ? = requested + = approved to proceed work - = denied, refused (Some though more needed about X and ?, as when bug is created it is always to be handled as request, not?) Plus a QA state flag: X = not ready to test (default, and set if someone is working on new solution) ? = please test / test in progress + = approved/yes - = test negative, solution need adjustment
<fake comment> Tested on 64 bit, but the package wouldn't start at all. It segfaults in the same way as before the update. </fake comment> I like flags :-) CC'ing QA team
CC: (none) => qa-bugsFlags: mga9-64-ok?(marja11) => mga9-64-ok-
(In reply to Marja Van Waes from comment #10) > <fake comment> > > Tested on 64 bit, but the package wouldn't start at all. It segfaults in the > same way as before the update. > > </fake comment> > > <fake comment> Oops. That was the old version Itested. Testing again with the current version, the package starts and works fine. Changing my mga9-64-ok- flag into mga9-64-ok+ </fake comment>
Flags: mga9-64-ok- => mga9-64-ok+
(In reply to Frédéric "LpSolit" Buclin from comment #4) > (In reply to katnatek from comment #3) > > Can link to a bugs with a flag like with keywords? like > > https://bugs.mageia.org/buglist.cgi?keywords=FOR_ERRATA9 > > Yes, for instance: > > https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata7- 24020 Mageia RPM Pack kde@ml.mageia.org NEW --- Plasma display problems when using nouveau driver on old NVIDIA GPUs 2023-07-11 998 Websites www.mage sysadmin-bugs@ml.mageia.org NEW --- O Brother, Where Art Thou? 2023-09-25 > > which is equivalent to: > > https://bugs.mageia.org/buglist.cgi?f1=flagtypes. > name&o1=equals&v1=in_errata7-&resolution=--- > ID Product Comp Assignee▲ Status▲ Resolution Summary Changed 24020 Mageia RPM Pack kde@ml.mageia.org NEW --- Plasma display problems when using nouveau driver on old NVIDIA GPUs 2023-07-11 998 Websites www.mage sysadmin-bugs@ml.mageia.org NEW --- O Brother, Where Art Thou? 2023-09-25 28349 Mageia Release watersnowrock@gmail.com RESO FIXE Plymouth from Mga7 is still shown after an upgrade to Mga8 2021-02-16 32416 Mageia RPM Pack qa-bugs@ml.mageia.org RESO FIXE Enlightenment desktop appears with background of Mageia 7 Tue 12:27 I see 2 bugs more with the second search This is very interesting and more flexible than keywords
(In reply to katnatek from comment #12) > I see 2 bugs more with the second search Yes, because Bugzilla truncated the link right after &resolution in my comment. It misses the =--- part.