When I attempt to set an RHBZ bug as EOL, I observe:
You must be a member of ‘fedora_pm’ to set resolution ‘EOL’ on product ‘Fedora’.
The reason that I want to is to avoid having lots of mail that I need to triage later, for bugs that I am unable to feasibly reproduce, which shall otherwise become EOL:
You might be able to volunteer for the Fedora Program Management job, but even if you did, I don’t think you are supposed to manually set that End of Life status. That gets set by script whenever a Fedora release goes end of life. You probably want to find a different status to close the bug with or else unsubscribe from the bug report.
Edit: Oh, I guess you are asking how to prevent that EOL status from being set? In that case, click the button to show the advanced options and change the version of Fedora Linux that the bug is reported against to a newer version (assuming the bug still exists).
@glb, you were originally correct. I know how to prevent the status being set, but I do not want to lie that I’ve reproduced these with a newer version.
However, I also don’t want to indicate with an alternative closure state that these are somehow infeasible to reproduce for anyone else. I merely don’t have the time to, and if they’re to be set as EOL anyway, I might as well save myself the mail:
Unsubscribing would have the unfortunate effect of meaning that I’d miss any potential responses, because users cannot be tagged on Bugzilla, and NEEDSINFO isn’t generally a 1:1 replacement for it.
I think if you don’t want the EOL email notifications, but you do want other types of email notifications, that is something you would have to do with mail filters on your email client. As far as I know, bugzilla does not have that sort of granularity with respect to what type of changes to notify people about.[1]
Maybe you could set your mail client to filter messages containing this bug will be closed as EOL?
I expect your next question might be “what if I want some EOL notifications, but not all of them?” In that case, maybe you could sneak some sort of marker (an innocuous character or word) in the subject line to indicate to yourself that you want to receive all notifications about the bug?
Sorry, that is the best I can come up with.
What change notifications you can set are listed here: https://bugzilla.redhat.com/userprefs.cgi?tab=email ↩︎
My understanding was that a reporter (you) can update any field in the bug:
I know that all members of the package maintainers and QA teams in FAS can update bugs. This is what I see in my bugzilla account permissions tab, for example:
I think “editbugs” is what we package maintainers and QA folks get, but I can’t find a source for this.
Can you see what your permissions are? Should be this link once you’re logged in:
@ankursinha, did you see what I’ve quoted?
You’re correct:
I’ve none that need to be explicitly granted:
Yes, I saw what you quoted, and I was mistaken—you can update a few fields, but not all of them.
In this case, you’re not a member of any FAS groups that correspond to the bugzilla group. So, you cannot modify other fields. You can apply to the QA/packager groups if you wish, and that should give you permissions. The idea there of course is that these groups need to actively work with bugs and require access.
@ankursinha, thanks. I don’t mind doing so, insofar as it doesn’t inherently confer additional responsibilities. Do you know where the process is documented?
Let me add some information here. 
The ‘fedora_pm’ group is for fedora project managers. It basically has
full permissions on everything fedora related in bugzilla. Things like
adding new components, or deleting everything or (as noted) setting bugs
to EOL. There’s a very very very few people in this group, and it’s
mostly used for automated (and well tested things) like adding new
components or closing eol bugs.
The ‘closed->EOL’ is restricted to this group because otherwise it would
be… wrong. If you closed this bug as EOL right now, it would be not
right. Fedora 42 is definitely not EOL yet. It would cause a lot of
confusion and there’s no reason to allow it, since all the fedora 42
bugs will be closed when fedora 42 actually is eol. 
I’d personally suggest you just close this bug as INSUFFICENT_DATA
since you don’t have data for it.
Hope that helps any…
Tertiary to your problem. There are bugs you don’t have time to replicate that are typically automatically assigned. Is there a way to spread these out further into the community to see A they can be replicated and as a second data point, and B to try and get more people involved in triage so they are at least easier to find. It would probably require some static documentation on finding and isolating bugs which may or may not exist.
I am thinking like Facebook groups and such.
Thanks, @kevin, although darn! I’ve just spend nearly 16 hours in a row settings bugs to WORKSFORME. Oh well; at least the Kamoso bug gets a more accurate status…
@solanum, although I’ve an inordinate amount, they’re not actually automatically assigned. I’ve merely experienced an impressive amount of crashes during the last two releases.
I expect that RHBZ is doomed, inasmuch as discovery is concerned. However, when Konqi allows me to transfer an Abrt bug from RHBZ to KDEBZ, that helps a lot. Otherwise, especially considering that Abrt shall be retired soon, and Konqi shall be a little more versatile, I’ll just need to become more used to reporting upstream.
Hopefully, the problem doesn’t merely replicate elsewhere:
Yes, this is for QA:
Package maintainers is more involved:
