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)

(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-bugs
Flags: 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.

I made a proposal in comment 5 which didn't get much feedback. Pushing this bug out of my TODO list.

Status: NEW => NEEDINFO

I think it is great.

@ Morgan and Katnatek

You two are as good as the only ones to handle the Errata. Do you agree to let Frédéric start by creating the in_errata10 flag?

After that, all teams could be asked which flags they'd like to have for their team.

(Flags like mga9-64-ok cannot be implemented without the cooperation of papoteur, because he needs to adjust madb to make sure that https://madb.mageialinux-online.org/updates/ still gives the correct information)

CC: (none) => bugsquad, doc-bugs, pkg-bugs
Flags: (none) => in_wiki?

(In reply to Marja Van Waes from comment #15)
> I think it is great.
> 
> @ Morgan and Katnatek
> 
> You two are as good as the only ones to handle the Errata. Do you agree to
> let Frédéric start by creating the in_errata10 flag?
> 
> After that, all teams could be asked which flags they'd like to have for
> their team.
> 
> (Flags like mga9-64-ok cannot be implemented without the cooperation of
> papoteur, because he needs to adjust madb to make sure that
> https://madb.mageialinux-online.org/updates/ still gives the correct
> information)

For me no exist issue the Whiteboard could be preserved until all in special
papoteur handle the flags, is not like have to be one or other right now or yes?

(In reply to katnatek from comment #16)

> 
> For me no exist issue the Whiteboard could be preserved until all in special
> papoteur handle the flags, is not like have to be one or other right now or
> yes?

You’re right, when LpSolit has time (still now, I hope), then he could add all proposed flags. 

@ papoteur

Could you adjust your script to temporarily (not months!) look at both flags and whiteboard, and later adjust it again to only look at the flags for the OKs? 

@ TJ and Lewis,

Sorry that you weren’t in the CC. The most important comment in this report is comment 3

CC: (none) => andrewsfarm, lewyssmith

(In reply to Marja Van Waes from comment 17)
> 
> Sorry that you weren’t in the CC. The most important comment in this report
> is comment 3

Make that comment 5

Hello,
MADb actually uses status_whiteboard field to extract information for bugs list:
xx as release number from MGAxxTOO
xx as release number and yy as bitness from MGAxx-yy.OK

I prefer to avoid to have 2 systems in parallel. If they are not in accordance, which one will be considered as the right one?

You assign priorities.

Doing a "cold turkey" change from one system to the other has its down side, too. In any group of people, some find it easier to adapt to a new situation than others.

OK, not as difficult to adapt to this as it was to adapt to driving the last tractor we bought. That thing has 12 speeds forward and 12 reverse, was my first experience with four wheel drive in a tractor, first front end loader, and with a snowblower for the back.

(In reply to papoteur from comment #19)
> Hello,
> MADb actually uses status_whiteboard field to extract information for bugs
> list:
> xx as release number from MGAxxTOO
> xx as release number and yy as bitness from MGAxx-yy.OK
> 
> I prefer to avoid to have 2 systems in parallel. If they are not in
> accordance, which one will be considered as the right one?

The flags.

Would it be better to temporarily have a default message in the Whiteboard: "Use flags and keywords"?

We should move "validated" out of the Whiteboard, too. 
I see that there are allready "validated_update" and "validated_backport". Why aren't they used?

(In reply to Thomas Andrews from comment #21)
> OK, not as difficult to adapt to this as it was to adapt to driving the last
> tractor we bought. That thing has 12 speeds forward and 12 reverse, was my
> first experience with four wheel drive in a tractor, first front end loader,
> and with a snowblower for the back.

LOL

(In reply to papoteur from comment #19)
> Hello,
> MADb actually uses status_whiteboard field to extract information for bugs
> list:

I cannot find the madb source code on gitweb.mageia.org. papoteur, where is the source code located ?

The code is at https://github.com/manatools/madb

CC: (none) => dan

I not see advantages of use flags if for new flags we need to call to
bugzilla¡s admin

The only interesting use I can think is each QA member set OK if the result of the test performed is good

Yes a flag can have more status than a whiteboard or keyword but that is all
don't know if enough to migrate, but if enough people agree to switch will be good for me

(In reply to katnatek from comment #26)
> I not see advantages of use flags if for new flags we need to call to
> bugzilla¡s admin

What do you mean by "call to bugzilla admin"? You mean to create new flag types? You already have to do that to create new keywords.

(In reply to Frédéric "LpSolit" Buclin from comment #27)
> (In reply to katnatek from comment #26)
> > I not see advantages of use flags if for new flags we need to call to
> > bugzilla¡s admin
> 
> What do you mean by "call to bugzilla admin"? You mean to create new flag
> types? You already have to do that to create new keywords.

Exactly my point
For the moment, use of flags sound more like a personal preference that a real advantage against the current workflow

(In reply to katnatek from comment #28)
> For the moment, use of flags sound more like a personal preference that a
> real advantage against the current workflow

Or based one someone who is using and has experience with Bugzilla for more than 20 years. But anyway, I won't fight with you on this topic.

CC: LpSolit => (none)
Flags: mga9-64-ok+, mga9-64-ok+, in_wiki? => (none)

(In reply to Frédéric "LpSolit" Buclin from comment #29)
> (In reply to katnatek from comment #28)
> > For the moment, use of flags sound more like a personal preference that a
> > real advantage against the current workflow
> 
> Or based one someone who is using and has experience with Bugzilla for more
> than 20 years. But anyway, I won't fight with you on this topic.

Don't take it as a fight, I not QA too much time ago, but I bug report since mandrake days, I just make personal impression also.

So I'm a few neutral to this change, and if others consider a must-have/something to not hurt if we switch

> 
> So I'm a few neutral to this change, and if others consider a
> must-have/something to not hurt if we switch

For me it's a must have. I've seen an important update not getting pushed, because instead of an OK on the whiteboard, there was an 0K. Toggling a flag is less work than writing or changing something on the whiteboard. Apart from that, I've seen some of my own searches not yielding everything they should, because of other typos.

I also prefer flags over having too many Keywords, so better to have the option to toggle between in_errata10? in_errata10- and in_errata10+  than having For_Errata_10 and In_Errata_10 keywords. 

Anyway, Frédéric is our Bugzilla maintainer. His opinion counts very much.
I don't want him to lose interest in maintaining Bugzilla. I want him to enjoy his work for Mageia.

From reading comments from the more experienced, I vote for flags.

We need an easily accessible clear description of how to use them - located in bugzilla, or maybe better linked to a page in our wiki so more people can write it.

We also need to keep a list of old keywords so we can search for them in old bugs.