Closing this bug.

Resolution: (none) => FIXED
Status: NEW => RESOLVED

Sorry, dmorgan. I'm using your bug to test flags (well, to convince QA that flags are great and useful). You can click the "Ignore Bug Mail" checkbox at the top right of the page to not get spam for this bug. :)


Pseudo-comments:

Things look good on Mageia 6 i586.

@David and Akien: can you test on Mageia 6 x86_64 if the solution proposed in this bug fixes this issue? ;)

@neoclust: can you check with Mageia 5 and GNOME as I know you still use it? :-p

It would be nice if someone else could also test on Mageia 5.

Resolution: FIXED => (none)
Ever confirmed: 1 => 0
CC: (none) => davidwhodgins, LpSolit, mageia, rverschelde
Flags: (none) => test-mga5-32?, test-mga5-64?(mageia), test-mga6-64?(davidwhodgins), test-mga6-64?(rverschelde), test-mga6-32+
Summary: test => test flags (a.k.a flags are great!)
Status: RESOLVED => UNCONFIRMED

(In reply to Frédéric Buclin from comment #2)

> Pseudo-comments:
<snip>
> 
> It would be nice if someone else could also test on Mageia 5.

More pseudo-comments:

32 bit Mga5 tested fine here, using XFCE, but 64bit (again with XFCE) failed.

Was it OK to add a set of flags to be able to set another test-mga5-64 flag (since the existing one seemed meant for neoclust) and to set the already existing one for test-mga5-32?

How many sets of test-mga*-* flags can be created in one bug report?

CC: (none) => marja11
Flags: test-mga5-32? => test-mga5-32+, test-mga5-64-

In the set of flags I added only the one I had set to "-" was kept.... I think I had also set one to "?", with LpSolit in the field next to it... will test that again

Another pseudo-comment:

tested with Mate now, Mga5 64bit, and the test fails again.
Adding  "test-mga5-64" "-", but also adding 
"test-mga5-32" "?" "LpSolit@netscape.net, "
because I want to see that that gets saved :-)

Flags: (none) => test-mga5-32?(LpSolit), test-mga5-64-

(In reply to Marja van Waes from comment #4)
> but also adding 
> "test-mga5-32" "?" "LpSolit@netscape.net, "
> because I want to see that that gets saved :-)

it does :-D

(In reply to Marja van Waes from comment #3)
> Was it OK to add a set of flags to be able to set another test-mga5-64 flag
> (since the existing one seemed meant for neoclust) and to set the already
> existing one for test-mga5-32?

It is totally fine. :)

 
> How many sets of test-mga*-* flags can be created in one bug report?

Unlimited. You can even create several flags of the same type at once by listing users in the "requestee" field. For instance:

test-mga6-64?marja,lpsolit will create two requests:

test-mga6-64?marja
test-mga6-64?lpsolit

Cool, isn't it? :)


Pseudo-comment:

(In reply to Marja van Waes from comment #3)
> 32 bit Mga5 tested fine here, using XFCE

It fails when testing with LXQt. I get a blank screen. No idea why.

End of pseudo-comment.



Note that with flags, we now have:

marja11: test-mga5-32+
LpSolit: test-mga5-32-

So without reading comments, you already see that at least one tester had problems with Mageia 5 i586. So you know it would be inappropriate to add the MGA5-32-OK keyword.

@David: I think this is a good demonstration of why flags would be useful. Because each tester is free to set his own flag. This doesn't impact what other testers say, and you have an immediate global view of the situation.

Flags: test-mga5-32?(LpSolit) => test-mga5-32-

Testing flags...

pclx: test-mga5-64+

Flags: (none) => test-mga5-64+
CC: (none) => mageia

(In reply to Frédéric Buclin from comment #6)

In reply to my earlier:  Flags: (none) => test-mga5-32?(LpSolit@netscape.net),
you did:
Flags: test-mga5-32?(LpSolit@netscape.net) => test-mga5-32-

I received a new type of Bugzilla mail about that, one that has no footer, but has this at the top of the mail:


> Frédéric Buclin <LpSolit@netscape.net> has denied Marja van Waes
> <marja11@xs4all.nl>'s request for Frédéric Buclin <LpSolit@netscape.net>'s
> test-mga5-32:
> Bug 5: test flags (a.k.a  flags are great!)
> https://bugs.mageia.org/show_bug.cgi?id=5

I think for flags about testing that message is confusing: I asked you to test with mga5-32, that's what you did and the test failed. If you had denied my request, you wouldn't have tested ;-)

However, getting a separate mail about the flag-request is great!

Is a message like this one generic enough for all kinds of flags?:

> Frédéric Buclin <LpSolit@netscape.net> has responded to Marja van Waes
> <marja11@xs4all.nl>'s request for Frédéric Buclin <LpSolit@netscape.net>'s
> test-mga5-32:
> Flags: test-mga5-32?(LpSolit@netscape.net) => test-mga5-32-
> Bug 5: test flags (a.k.a  flags are great!)
> https://bugs.mageia.org/show_bug.cgi?id=5

(Or is it possible to have different messages for different flag types?)

(removing duplicated flags)

(In reply to Marja van Waes from comment #8)
> I received a new type of Bugzilla mail about that

Yes, they are called flag mails, which are different from the usual bug mails.


> I think for flags about testing that message is confusing: I asked you to
> test with mga5-32, that's what you did and the test failed. If you had
> denied my request, you wouldn't have tested ;-)

That's the default flag mail. :) Upstream, we had to be as generic as possible to match as many words for the flag name as possible.


> (Or is it possible to have different messages for different flag types?)

Not by default, but I could customize them if needed.


Anyway, per David Hodgins in bugsquad@, I have the feeling that he doesn't want flags in the QA process. :(

Flags: test-mga5-64-, test-mga5-64+, test-mga6-64?(davidwhodgins) => (none)

Created attachment 9607 [details]
ignore me

No longer needed.

Status: UNCONFIRMED => RESOLVED
Resolution: (none) => OLD
Assignee: dmorganec => sysadmin-bugs

reopening to test flag creation

Status: RESOLVED => UNCONFIRMED
Resolution: OLD => (none)

Sorry to close the bug you was using to this

We have a few set of flag for the moment

Flags: (none) => 10A1_round3-

I think the "(more flags)" should be "(more testers)" because adding testers is all it can do here?

(In reply to Morgan Leijström from comment #15)
> I think the "(more flags)" should be "(more testers)" because adding testers
> is all it can do here?

(more flags) is hardcoded in Bugzilla and should stay as is, IMO. I think there will be more flags than just testing: in_errata, in_release_notes, need_info, validated_update, validated_backport, blocking_alpha2, blocking_beta1, blocking_rc, blocking_final, pass_tests come to mind. With these generic terms, they will be reusable for each new major version of Mageia; no need to reword them.

I think that 10A1_round3 is too cryptic and should be renamed to affects_10alpha1_r3. Also, I don't think this flag should be multiplicable, nor should it be specifically requestable (I'm using the wording Marja can read on the flag config page). People are supposed to test if a bug is reproducible on their machine, which the pass_tests flag above would be for. And if at least N QA testers (N >= 1, I will let the QA team leader decide) find a bug, then leaders of the QA team can set the flag to affects_10alpha1_r3+.

Oh, and another useful flag would be affects_mga9 instead of MGA9TOO in the status whiteboard, which is prone to typos.

Good ideas.

BTW, how to do to add a flag with specific name?
"(more flags)" for me only gives another "10A1_round3" prepended by "addl."

(In reply to Morgan Leijström from comment #18)
> BTW, how to do to add a flag with specific name?
> "(more flags)" for me only gives another "10A1_round3" prepended by "addl."

New flag types must be created from the administration page:

https://bugs.mageia.org/editflagtypes.cgi

Once they are created, they will be available in bug reports.

(In reply to Frédéric "LpSolit" Buclin from comment #16)
> (In reply to Morgan Leijström from comment #15)
> > I think the "(more flags)" should be "(more testers)" because adding testers
> > is all it can do here?
> 
> (more flags) is hardcoded in Bugzilla and should stay as is, IMO. I think
> there will be more flags than just testing: in_errata, in_release_notes,
> need_info, validated_update, validated_backport, blocking_alpha2,
> blocking_beta1, blocking_rc, blocking_final, pass_tests come to mind. With
> these generic terms, they will be reusable for each new major version of
> Mageia; no need to reword them.
> 
> I think that 10A1_round3 is too cryptic and should be renamed to
> affects_10alpha1_r3. Also, I don't think this flag should be multiplicable,
> nor should it be specifically requestable (I'm using the wording Marja can
> read on the flag config page). People are supposed to test if a bug is
> reproducible on their machine, which the pass_tests flag above would be for.
> And if at least N QA testers (N >= 1, I will let the QA team leader decide)
> find a bug, then leaders of the QA team can set the flag to
> affects_10alpha1_r3+.

need_info is a bug status
we already have validated_update, validated_backport keywords, so I think those flags are not necessary

(In reply to katnatek from comment #20)
> need_info is a bug status

I know, but when you set the bug status to NEEDINFO, it's unclear who must provide more information, unless you read all the comments to find it. When someone sets the bug status to NEEDINFO, he should also set the need_info flag to the specific user(s). The advantages of doing this are multiple:

- Flags are displayed at the top of bug reports. No need to read all comments to know whom we are waiting for more information.

- The user automatically gets an email addressed to him asking him for more information, even if the user is not in the CC list of the bug. Personally, I much prefer to get a single mail asking me for more information or data than being CC'ed to a bug and getting emails for all new comments. Much less spam!

- Moreover, all requests addressed to you or made by you are collected in a single place and accessible from the "My Requests" link you can see in the page header and footer of Bugzilla (when you are logged in). For instance, here are all my requests at bugzilla.mozilla.org:

https://bugzilla.mozilla.org/request.cgi?requester=LpSolit%40gmail.com&requestee=LpSolit%40gmail.com&do_union=1&group=type&action=queue

Another example: here are all needinfo requests for Bugzilla upstream:

https://bugzilla.mozilla.org/request.cgi?action=queue&product=Bugzilla&type=needinfo&group=requestee


> we already have validated_update, validated_backport keywords, so I think
> those flags are not necessary

I still think they would make sense as flags instead of keywords. When enough QA testers have tested a new RPM, they can set the flag to e.g. validated_update?, and the QA leader can then see these requests and set them to validated_update+ if he thinks that there has been enough testing.

(In reply to katnatek from comment #13)
> Sorry to close the bug you was using to this

No problem , I wanted to go slowly, with one flag at a time, but being "forced" to continue here I can try more things...

(In reply to katnatek from comment #14)
> We have a few set of flag for the moment

and I can (did already) add more flags while still not really understanding how it works.

(In reply to Frédéric "LpSolit" Buclin from comment #16)
> (In reply to Morgan Leijström from comment #15)
> > I think the "(more flags)" should be "(more testers)" because adding testers
> > is all it can do here?
> 
> (more flags) is hardcoded in Bugzilla and should stay as is, IMO. I think
> there will be more flags than just testing: in_errata, in_release_notes,
> need_info, validated_update, validated_backport, blocking_alpha2,
> blocking_beta1, blocking_rc, blocking_final, pass_tests come to mind. With
> these generic terms, they will be reusable for each new major version of
> Mageia; no need to reword them.

And how to handle different versions of release notes and errata, if a bug should be in the versions for Mageia 9, 10 and 11?

> 
> I think that 10A1_round3 is too cryptic and should be renamed to
> affects_10alpha1_r3. Also, I don't think this flag should be multiplicable,
> nor should it be specifically requestable (I'm using the wording Marja can
> read on the flag config page). 

Done

I still don't understand all of what I'm doing, though. 
Please look at the 3 flags I created so far and tell whether it makes sense what I did :-)

CC: mageia => (none)
Flags: (none) => need_info?(LpSolit)

(In reply to Marja Van Waes from comment #22)
> And how to handle different versions of release notes and errata, if a bug
> should be in the versions for Mageia 9, 10 and 11?

in_errata9, in_errata10, in_release_notes9, in_release_notes10, etc...


> I still don't understand all of what I'm doing, though. 
> Please look at the 3 flags I created so far and tell whether it makes sense
> what I did :-)

I updated them a bit: need_info can be useful everywhere, not only for the Mageia product. I also reworded its description, because once information has been given, you generally can clear the flag instead of keeping it forever. But setting it to '+' doesn't hurt.

Flags: need_info?(LpSolit) => (none)

(In reply to Frédéric "LpSolit" Buclin from comment #23)
> (In reply to Marja Van Waes from comment #22)
> > And how to handle different versions of release notes and errata, if a bug
> > should be in the versions for Mageia 9, 10 and 11?
> 
> in_errata9, in_errata10, in_release_notes9, in_release_notes10, etc...

Good, so that covers what we had.
> 
> 
> > I still don't understand all of what I'm doing, though. 
> > Please look at the 3 flags I created so far and tell whether it makes sense
> > what I did :-)
> 
> I updated them a bit: need_info can be useful everywhere, not only for the
> Mageia product. I also reworded its description, because once information
> has been given, you generally can clear the flag instead of keeping it
> forever. But setting it to '+' doesn't hurt.

Thanks, will take a look.

One more question:
When I do  a custom search, all fields default, but Custom Search:

Match ALL of the following separately:

FLAGS      contains the string     affects_10A1_round3 

This bug doesn't show up. What do I miss?

Trying to set need_info for Marja

Flags: (none) => need_info?(marja11)

(In reply to Marja Van Waes from comment #24)
> One more question:
> When I do  a custom search, all fields default, but Custom Search:
> 
> Match ALL of the following separately:
> 
> FLAGS      contains the string     affects_10A1_round3 
> 
> This bug doesn't show up. What do I miss?


That's because I renamed the flag to affects_10alpha1_r3. :)

(In reply to Frédéric "LpSolit" Buclin from comment #26)

> 
> 
> That's because I renamed the flag to affects_10alpha1_r3. :)

LOL(In reply to papoteur from comment #25)
> Trying to set need_info for Marja

You were successfull. Clicking X doesn't immediately remove it, here.

(In reply to Marja Van Waes from comment #24)

> 
> One more question:
> When I do  a custom search, all fields default, but Custom Search:
> 
> Match ALL of the following separately:
> 
> FLAGS      contains the string     affects_10A1_round3 
> 
> This bug doesn't show up. What do I miss?

Doing the same with "affects_mga9" gives a long list, though.

"affects_mga9+" givest the same list (as it should, atm)
"affects_mga9-" returns nothing (also as it should, now)

That's really nice :-)

Flags: need_info?(marja11) => (none)

@ papoteur

I haven't yet asked on dev, qa-discuss and bugs-discuss mls, to click on "set flags" in 

"Flags: None yet set (set flags)" 

below the Source RPM: and Status comment: fields on the right

and to then select "affects_mga9" and set it to + 

instead of adding MGA9TOO again for bugs that did until now get that string on the whiteboard.

I'd like to wait with that until you've adjusted your madb code, is that OK?

Once that mail is sent, the flag should take priority over the whiteboard.

Flags: (none) => need_info?(yves.brungard)

(In reply to Frédéric "LpSolit" Buclin from comment #21)
> (In reply to katnatek from comment #20)
> > need_info is a bug status
> 
> I know, but when you set the bug status to NEEDINFO, it's unclear who must
> provide more information, unless you read all the comments to find it. When
> someone sets the bug status to NEEDINFO, he should also set the need_info
> flag to the specific user(s). The advantages of doing this are multiple:
> 
> - Flags are displayed at the top of bug reports. No need to read all
> comments to know whom we are waiting for more information.
> 
> - The user automatically gets an email addressed to him asking him for more
> information, even if the user is not in the CC list of the bug. Personally,
> I much prefer to get a single mail asking me for more information or data
> than being CC'ed to a bug and getting emails for all new comments. Much less
> spam!
> 
As long as I see the NEEDINFO status almost always is directec to bug's reporter and when not is set when reply to a comment fir other user, but I will buy you the customization part, for unwanted mails is not diferent to add user to CC, if the requester or the user don't remove you will get all future mails in the bug, like happened to me when you show me how it works, and even could get dupkicated mails if I'm the bug reporter like was for me with Marja's request in bug#33700 	

But now that is created the flag lets see how we work with it

> 
> > we already have validated_update, validated_backport keywords, so I think
> > those flags are not necessary
> 
> I still think they would make sense as flags instead of keywords. When
> enough QA testers have tested a new RPM, they can set the flag to e.g.
> validated_update?, and the QA leader can then see these requests and set
> them to validated_update+ if he thinks that there has been enough testing.

As the team leader decide in base to test results set the validated_update, validated_backport keywords, I suggest use test_ok or test_result, or even replace the mgaNbitsOK whiteboard instead use validated_update, validated_backport as flags

(In reply to katnatek from comment #29)
> for unwanted mails is not diferent to
> add user to CC, if the requester or the user don't remove you will get all
> future mails in the bug, like happened to me when you show me how it works,

To not get future emails, make sure you are not automatically CC'ed to the bug:

https://bugs.mageia.org/userprefs.cgi?tab=settings

Check the "Automatically add me to the CC list of bugs I am requested to review" and turn it off.

(In reply to Frédéric "LpSolit" Buclin from comment #30)
> (In reply to katnatek from comment #29)
> > for unwanted mails is not diferent to
> > add user to CC, if the requester or the user don't remove you will get all
> > future mails in the bug, like happened to me when you show me how it works,
> 
> To not get future emails, make sure you are not automatically CC'ed to the
> bug:
> 
> https://bugs.mageia.org/userprefs.cgi?tab=settings
> 
> Check the "Automatically add me to the CC list of bugs I am requested to
> review" and turn it off.

Then is a thing that should be documented, perhaps here https://wiki.mageia.org/en/Bugzilla

As reported by papoteur in bug #31993, comment #33 he did not (yet) find a way to get madb to read flags.

So instead of adding any flags to replace Whiteboard strings that are needed by Madb, I suggest adding the ones for the Release Notes and Errata additions.

@ katnatek
@ morgan

WDYT?

@LpSolit

In order to let the In_Errata10 flag correctly cover FOR_ERRATA10 and IN_ERRATA10, should it be like this? Or like the second example below this? :

- - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - -- -

Description.

This flag tracks whether bugs that should be in the Mageia 10 Errata, have been added.

In_Errata10 ?   Requested by a user to add it to the Errata.
In_Errata10 +   It has been added 
In_Errata10 -   It's not in there, but should be

Denying the request, would mean entirely removing the flag.

- - - - - - - - - - -- - - - - - - - - - -- - - - -- --- - -- - - - -- - - -- 

Or with + and - be reverted:

Description.

This flag tracks whether bugs that should be in the Mageia 10 Errata, are still missing from it.

In_Errata10 ?   Requested by a user to add it to the Errata.
In_Errata10 +   It is still missing 
In_Errata10 -   It's no longer missing.

Denying the request, would mean entirely removing the flag

(In reply to Marja Van Waes from comment #32)
> In order to let the In_Errata10 flag correctly cover FOR_ERRATA10 and
> IN_ERRATA10, should it be like this? Or like the second example below this? :
> 
> - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - --
> -
> 
> Description.
> 
> This flag tracks whether bugs that should be in the Mageia 10 Errata, have
> been added.
> 
> In_Errata10 ?   Requested by a user to add it to the Errata.
> In_Errata10 +   It has been added 
> In_Errata10 -   It's not in there, but should be
> 
> Denying the request, would mean entirely removing the flag.

It should be like the first one, with one modification: denying the request, which means setting the flag to in_errata10-, should mean "we don't need it in the errata". So if it should be in the errata, but is not yet, then the flag should stay as in_errata10? till someone writes something in the errata.

(In reply to Frédéric "LpSolit" Buclin from comment #33)
> (In reply to Marja Van Waes from comment #32)
> > In order to let the In_Errata10 flag correctly cover FOR_ERRATA10 and
> > IN_ERRATA10, should it be like this? Or like the second example below this? :
> > 
> > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - --
> > -
> > 
> > Description.
> > 
> > This flag tracks whether bugs that should be in the Mageia 10 Errata, have
> > been added.
> > 
> > In_Errata10 ?   Requested by a user to add it to the Errata.
> > In_Errata10 +   It has been added 
> > In_Errata10 -   It's not in there, but should be
> > 
> > Denying the request, would mean entirely removing the flag.
> 
> It should be like the first one, with one modification: denying the request,
> which means setting the flag to in_errata10-, should mean "we don't need it
> in the errata". So if it should be in the errata, but is not yet, then the
> flag should stay as in_errata10? till someone writes something in the errata.

Thanks, so Keyword FOR_ERRATA10 = Flag In_Errata10 ?
           Keyword IN_ERRATA10  = Flag In_Errata10 +
     
And In_Errata10 - means: it should not be added.

I created it and chose to only let the editbugs group grant it. That group includes packagers, QA team and Bugsquad, doesn't it?

(In reply to Marja Van Waes from comment #34)

> 
> I created it and chose to only let the editbugs group grant it. That group
> includes packagers, QA team and Bugsquad, doesn't it?

hmm, seems I didn't, don't see it here

(In reply to Marja Van Waes from comment #35)
> hmm, seems I didn't, don't see it here

That's because you forgot to make it active. I activated it. Reload the page. :)

Just for consistency, I think all flag names should be Like_This, or like_this. I have a personal preference for lowercase flag names, but I will let you decide. :)

(In reply to Frédéric "LpSolit" Buclin from comment #37)
> Just for consistency, I think all flag names should be Like_This, or
> like_this. I have a personal preference for lowercase flag names, but I will
> let you decide. :)

I'll go with like_this. 

(In reply to Frédéric "LpSolit" Buclin from comment #36)
> (In reply to Marja Van Waes from comment #35)
> > hmm, seems I didn't, don't see it here
> 
> That's because you forgot to make it active. I activated it. Reload the
> page. :)

I fail to see how I could have made it active. I shouldn't have started by copying an inactive flag ;-)

(In reply to Marja Van Waes from comment #34)
> Thanks, so Keyword FOR_ERRATA10 = Flag In_Errata10 ?
>            Keyword IN_ERRATA10  = Flag In_Errata10 +
>      
> And In_Errata10 - means: it should not be added.

Yes, correct.


> I created it and chose to only let the editbugs group grant it. That group
> includes packagers, QA team and Bugsquad, doesn't it?

Packagers yes, bugsquad yes, but there was no mga-qa group in Bugzilla. So I created it.

(In reply to Frédéric "LpSolit" Buclin from comment #39)

> 
> > I created it and chose to only let the editbugs group grant it. That group
> > includes packagers, QA team and Bugsquad, doesn't it?
> 
> Packagers yes, bugsquad yes, but there was no mga-qa group in Bugzilla. So I
> created it.

Thanks :-)

@ katnatek
@ morgan

Please take a look at the two new flags, in_errata10 and in_release_notes10, hover over them to see the description and feel free to play with them.

(In reply to Frédéric "LpSolit" Buclin from comment #39)
> (In reply to Marja Van Waes from comment #34)
> > Thanks, so Keyword FOR_ERRATA10 = Flag In_Errata10 ?
> >            Keyword IN_ERRATA10  = Flag In_Errata10 +
> >      
> > And In_Errata10 - means: it should not be added.
> 
> Yes, correct.

And like we have been using keyword FOR_ERRATAX i think we Flag In_ErrataX ? can also mean the entry is to be edited:
  When written/revised/updated OK, set Flag In_ErrataX +
  If we removed entry and it should be kept removed, set Flag In_ErrataX -

Flags: (none) => affects_mga9-

?! I did not flip a flag when i sent Comment 41.
Did browser cache a previous state?

(In reply to Marja Van Waes from comment #40)
> Please take a look at the two new flags, in_errata10 and in_release_notes10,
> hover over them to see the description and feel free to play with them.

Good, but in line with my comment 41, for the state "?": "Please add or edit"...

(In reply to Morgan Leijström from comment #42)
> ?! I did not flip a flag when i sent Comment 41.
> Did browser cache a previous state?

Doubtful, because the affects_mga9 flag has never been touched in this bug before.

Make some test and add links with search with flags instead keywords, is working, so we start to flag in_errtas10? and in_errtas10+ , and remove the equivalent keywords for_errratas10 & in_erratas10

When all that keywords are removed, we can remove the links in the errata page

(In reply to Morgan Leijström from comment #43)

> Good, but in line with my comment 41, for the state "?": "Please add or
> edit"...

Done.

@ Frédéric,

Atm, hoovering only shows the description when I hoover somewhere near the top of the first "i", just under the dot.
After right clicking a few ties, the description only becomes visible when clicking the right leg of the n in "in". So it is rather hard to see the description.
Using firefox-beta-145.0-0.b9.mga10 in cauldron, is that a firefox issue?
On my phone, I can't get the description og the flags at all (Firefox 146.1)

(In reply to katnatek from comment #45)
> Make some test and add links with search with flags instead keywords, is
> working, so we start to flag in_errtas10? and in_errtas10+ , and remove the
> equivalent keywords for_errratas10 & in_erratas10
> 
> When all that keywords are removed, we can remove the links in the errata
> page

Note that it is possible to mass-change all the bugs with these keywords so that they get the correct flags.

(In reply to Marja Van Waes from comment #47)
> (In reply to katnatek from comment #45)
> > Make some test and add links with search with flags instead keywords, is
> > working, so we start to flag in_errtas10? and in_errtas10+ , and remove the
> > equivalent keywords for_errratas10 & in_erratas10
> > 
> > When all that keywords are removed, we can remove the links in the errata
> > page
> 
> Note that it is possible to mass-change all the bugs with these keywords so
> that they get the correct flags.

I don't know how or if I can do that, for the moment I make some manual changes

(In reply to katnatek from comment #48)
> (In reply to Marja Van Waes from comment #47)
> > Note that it is possible to mass-change all the bugs with these keywords so
> > that they get the correct flags.
> 
> I don't know how or if I can do that

Marja, educate us ! :-)

(In reply to Marja Van Waes from comment #46)
> Atm, hoovering only shows the description when I hoover somewhere near the
> top of the first "i", just under the dot.

Works fine for me. I wouldn't care too much about UI problems from a phone, because most people reporting problems into Bugzilla will do it from their desktop. And once you know what a flag is for, you won't read its description any longer.

Will do, but first:

(In reply to Marja Van Waes from comment #46)

> 
> @ Frédéric,
> 
> Atm, hoovering only shows the description when I hoover somewhere near the
> top of the first "i", just under the dot.
> After right clicking a few ties, the description only becomes visible when
> clicking the right leg of the n in "in". So it is rather hard to see the
> description.
> Using firefox-beta-145.0-0.b9.mga10 in cauldron, is that a firefox issue?
> On my phone, I can't get the description og the flags at all (Firefox 146.1)

Hoovering doesn't work in Konqueror and Falkon either, but I just noticed that if I right click in Falkon and choose to inspect the element, I can see the description in part of te source code of this page. However, repeating that I repeatedly got a different bit of the page :-/

(In reply to Frédéric "LpSolit" Buclin from comment #50)
> (In reply to Marja Van Waes from comment #46)
> > Atm, hoovering only shows the description when I hoover somewhere near the
> > top of the first "i", just under the dot.
> 
> Works fine for me. I wouldn't care too much about UI problems from a phone,
> because most people reporting problems into Bugzilla will do it from their
> desktop. And once you know what a flag is for, you won't read its
> description any longer.

Konqueror and Falkon were on a desktop. But I agree nearly no one will care.

Perhaps my links are not as good as I think
https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata10?
https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata10+

Give me common results, that is not what I was expecting

(In reply to katnatek from comment #53)
> Perhaps my links are not as good as I think
> https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata10?
> https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata10+
> 
> Give me common results, that is not what I was expecting

They work for me. What did you expect as results?

(In reply to Frédéric "LpSolit" Buclin from comment #54)
> (In reply to katnatek from comment #53)
> > Perhaps my links are not as good as I think
> > https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata10?
> > https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata10+
> > 
> > Give me common results, that is not what I was expecting
> 
> They work for me. What did you expect as results?

By example

https://bugs.mageia.org/show_bug.cgi?id=20835 is in the first link and not
in the second

(In reply to Morgan Leijström from comment #49)
> (In reply to katnatek from comment #48)
> > (In reply to Marja Van Waes from comment #47)
> > > Note that it is possible to mass-change all the bugs with these keywords so
> > > that they get the correct flags.
> > 
> > I don't know how or if I can do that
> 
> Marja, educate us ! :-)

I nearly finished and then my tab disappeared and I can't restore it. 
Will write it again outside FF and then paste it here.

(In reply to katnatek from comment #55)
> (In reply to Frédéric "LpSolit" Buclin from comment #54)
> > (In reply to katnatek from comment #53)
> > > Perhaps my links are not as good as I think
> > > https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata10?
> > > https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata10+
> > > 
> > > Give me common results, that is not what I was expecting
> > 
> > They work for me. What did you expect as results?
> 
> By example
> 
> https://bugs.mageia.org/show_bug.cgi?id=20835 is in the first link and not
> in the second

More clear, I expect the bug are in the list of first link but not in the list of the second link

https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Din_errata10%2B

only returns bug 34205, which has in_errata10+.


https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Din_errata10%3F

returns bugs 20835, 27117, 32290 which all have in_errata10?.


https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Ain_errata10

returns all the four bugs mentioned above, as they all have the in_errata10 set, Here, +, - or ? doesn't matter.

(In reply to Morgan Leijström from comment #49)
> (In reply to katnatek from comment #48)
> > (In reply to Marja Van Waes from comment #47)
> > > Note that it is possible to mass-change all the bugs with these keywords so
> > > that they get the correct flags.
> > 
> > I don't know how or if I can do that
> 
> Marja, educate us ! :-)


- Click on Search
. Advanced Search
- Custom Search (near the bottom of the page)
. Match ALL of the following seperately
. Keywords - contains the string - FOR_ERRATA10


Click on Search at the bottom left

You get a list of bugs.

Below them, click on "Change several bugs at once"

then click, again below the list, on Check ALL

Then further down, you can select "Delete these keywords" (by toggling "Add these keywords") and then enter "FOR_ERRATA10"

Below the comments field, in the flags section, click on "do not change" next to  "in_errata10" and select the question mark (?)

After adding a comment, go to the somewhat hidded button "Commit" on the left, below "Flags" and "Groups" and click on it.

(In reply to Frédéric "LpSolit" Buclin from comment #58)
> https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Din_errata10%2B
> 
> only returns bug 34205, which has in_errata10+.
> 
> 
> https://bugs.mageia.org/buglist.cgi?quicksearch=flag%3Din_errata10%3F
> 
> returns bugs 20835, 27117, 32290 which all have in_errata10?.
> 
That works Thank you

(In reply to Marja Van Waes from comment #59)
> (In reply to Morgan Leijström from comment #49)
> > (In reply to katnatek from comment #48)
> > > (In reply to Marja Van Waes from comment #47)
> > > > Note that it is possible to mass-change all the bugs with these keywords so
> > > > that they get the correct flags.
> > > 
> > > I don't know how or if I can do that
> > 
> > Marja, educate us ! :-)
> 
> 
> - Click on Search
> . Advanced Search
> - Custom Search (near the bottom of the page)
> . Match ALL of the following seperately
> . Keywords - contains the string - FOR_ERRATA10
> 
> 
> Click on Search at the bottom left
> 
> You get a list of bugs.
> 
> Below them, click on "Change several bugs at once"
> 
> then click, again below the list, on Check ALL
> 
> Then further down, you can select "Delete these keywords" (by toggling "Add
> these keywords") and then enter "FOR_ERRATA10"
> 
> Below the comments field, in the flags section, click on "do not change"
> next to  "in_errata10" and select the question mark (?)
> 
> After adding a comment, go to the somewhat hidded button "Commit" on the
> left, below "Flags" and "Groups" and click on it.

It was funny XD , still have to change the flags for closed bugs

Is it possible to make "Flags:" to be a link (like the other headers like "See also:" are?

Then it can point to a relevant section "Bug flags" in https://wiki.mageia.org/en/Bugzilla, 

- and can Frédéric or Marja author such a section please?

Morgan did you want to play with instructions from comment#59 changing the keywords
to FOR_RELEASENOTES10 & IN_RELEASENOTES10 ?

Or do you want I make the change?

(In reply to Frédéric "LpSolit" Buclin from comment #30)
> (In reply to katnatek from comment #29)
> > for unwanted mails is not diferent to
> > add user to CC, if the requester or the user don't remove you will get all
> > future mails in the bug, like happened to me when you show me how it works,
> 
> To not get future emails, make sure you are not automatically CC'ed to the
> bug:
> 
> https://bugs.mageia.org/userprefs.cgi?tab=settings
> 
> Check the "Automatically add me to the CC list of bugs I am requested to
> review" and turn it off.

It's turned off by default, so add one mail through a flag ignore this setting
Other thing that bothered me is I receive an extra mail from bugzilla when I remove a flag (perhaps other changes like status change?) that I set

(In reply to katnatek from comment #64)
> It's turned off by default, so add one mail through a flag ignore this
> setting

I changed to default to off *after* you mentioned it, so it's working correctly.


> Other thing that bothered me is I receive an extra mail from bugzilla when I
> remove a flag (perhaps other changes like status change?) that I set

Yes, that's expected, because you removed a flag you set yourself, and the setter of a flag is always notified independently (useful when you are not CC'ed to a bug).

(In reply to katnatek from comment #64)
> Other thing that bothered me is I receive an extra mail from bugzilla when I
> remove a flag (perhaps other changes like status change?) that I set

If you really dislike getting a specific email about flags, you can turn off this checkbox in your preferences:

[X] Email me when someone sets a flag I asked for

(In reply to Frédéric "LpSolit" Buclin from comment #66)
Thank you one more time

(In reply to katnatek from comment #63)
> Morgan did you want to play with instructions from comment#59 changing the
> keywords
> to FOR_RELEASENOTES10 & IN_RELEASENOTES10 ?
> 
> Or do you want I make the change?

Please go ahead :-)

From comment 62, i would be nice with a
> section "Bug flags" in https://wiki.mageia.org/en/Bugzilla,

Flags: (none) => in_wiki?

(In reply to Morgan Leijström from comment #69)
> From comment 62, i would be nice with a
> > section "Bug flags" in https://wiki.mageia.org/en/Bugzilla,

Done, https://wiki.mageia.org/en/Bugzilla#Flags

Flags: in_wiki? => in_wiki+

Thanks Marja!
This is also for me a lesson to use flags :)

I noticed that when you set in_wiki +, i got email with subject
"in_wiki granted: [Bug 5] test flags (a.k.a flags are great!)"
i.e flag change + bug

test what happens to 
 	
fri: 	affects_10alpha1_r3  +

when I change his (Morgan's) + to -

Flags: affects_10alpha1_r3+ => affects_10alpha1_r3-

(In reply to Marja Van Waes from comment #72)
> test what happens to 
>  	
> fri: 	affects_10alpha1_r3  +
> 
> when I change his (Morgan's) + to -

That's good, it became:

marja11: 	affects_10alpha1_r3  -

I was wondering, because in bug 31993

LpSolit: 	test_passed_mga9_64 ? <e-mail address>

kept LpSolit at the beginning when I changed the e-mail address in it:

LpSolit: 	test_passed_mga9_64 ? <another e-mail address>

(In reply to Marja Van Waes from comment #73)
> I was wondering, because in bug 31993
> 
> LpSolit: 	test_passed_mga9_64 ? <e-mail address>
> kept LpSolit at the beginning when I changed the e-mail address in it:
> LpSolit: 	test_passed_mga9_64 ? <another e-mail address>

That's because you reassigned the request to someone else. So it only changes the requestee, not the requester.

Can the needinfo textbox be in new line 
Or the flag space somewhere else in the left , the textbox of need info is too small

(In reply to katnatek from comment #75)
> Can the needinfo textbox be in new line 
> Or the flag space somewhere else in the left , the textbox of need info is
> too small

Unless you use a very small screen, the field is large enough. This is will be improved once I'm done with bug 34432.

Flags: (none) => need_info?

Created attachment 15303 [details]
Texbox of needinfo

(In reply to Frédéric "LpSolit" Buclin from comment #76)
> (In reply to katnatek from comment #75)
> > Can the needinfo textbox be in new line 
> > Or the flag space somewhere else in the left , the textbox of need info is
> > too small
> 
> Unless you use a very small screen, the field is large enough. This is will
> be improved once I'm done with bug 34432.
Not for me

Created attachment 15304 [details]
need_info flag screenshot

Here is what I see

(In reply to Frédéric "LpSolit" Buclin from comment #78)
> Created attachment 15304 [details]
> need_info flag screenshot
> 
> Here is what I see

Weird could be the version of browser as I use firefox from mozilla in my desktop

(In reply to katnatek from comment #79)
> Weird could be the version of browser as I use firefox from mozilla in my
> desktop

I use Firefox too, version 146.0.1.

(In reply to Frédéric "LpSolit" Buclin from comment #80)
> (In reply to katnatek from comment #79)
> > Weird could be the version of browser as I use firefox from mozilla in my
> > desktop
> 
> I use Firefox too, version 146.0.1.

It looks differrent depending on whether or not you are logged in.

If you're logged in, it shows the the drop down button for each line of flags
and everything lines up vertically. I you are not logged in, the button is
not shown and the text does not line up vertically.

(In reply to Frédéric "LpSolit" Buclin from comment #80)
> (In reply to katnatek from comment #79)
> > Weird could be the version of browser as I use firefox from mozilla in my
> > desktop
> 
> I use Firefox too, version 146.0.1.

What I think is your changes consider my LCD as small screen, and is small but not mobile device small ;)

(In reply to katnatek from comment #82)
> (In reply to Frédéric "LpSolit" Buclin from comment #80)
> > (In reply to katnatek from comment #79)
> > > Weird could be the version of browser as I use firefox from mozilla in my
> > > desktop
> > 
> > I use Firefox too, version 146.0.1.
> 
> What I think is your changes consider my LCD as small screen, and is small
> but not mobile device small ;)

In clean profile I can see a wide textbox but the font is too small for me
So I think my font configurations affect the result