Right now, my bot (@issuebot) is scanning Bugzilla periodically for entries filed against F35 and above which are tagged with the keyword CommonBugs. If it finds any, it will create a new issue in the category Propoposed Common Issues, and put a link back to this site in the bug Whiteboard field. When we’re confident the process is working, that link will point to the individual entry. For now, it will point here.
If that’s why you’re here and you’d like to see what this is all about, see the posts linked above. If you have a comment… comment below!
Also, can it please append the links to the end of the field, and not to the beginning (so that it doesn’t obscure words like AcceptedFreezeException and RejectedBlocker)?
Actually, from the same thread, it seems that change was intentional:
I will change @issuebot to work on F35 bugs even if they have the wiki link in the whiteboard, and it will create a bunch of new proposed topics for F35.
I am not sure what to do about moving from Proposed to “Accepted”. Anyone on the team should be able to do that — go ahead and try if you want, just put the topic back if you’re not really ready.
My current idea for official “promotion” is to key off of the reaction — if there are, say, three of those from members of the triage team, Issuebot will automatically move them — and also mark all replies, except any from Issuebot itself or any solution, as hidden, so as not to distract.
Yes, that’s great![1] I think it’s an interesting example of one user issue / problem (“sound isn’t working”) with two possible causes / bugs. In this case, they both happen to have one bugzilla entry, but we could actually do this when there are separate bugs. I’ll make a note to teach Issuebot that if there are two bugzilla links, to adjust the automatic comment to say that one of the linked bugs may be fixed.
If there were two separate bugs, Issuebot would create proposed issues for both, and we would:
pick one and explain both bugs, and edit the second bug link into the chosen issue topic
close the other one.
either manually adjust the Whiteboard in bugzilla for the un-chosen one to now point to the chosen topic instead of the original — or, have some sort of way to indicate that Issuebot should do that.
I’m not sure that combining is the right thing, though — what if one problem gets solved but the other doesn’t? Do we still mark the issue as solved? Not sure! Definitely need all of your thoughts for what this should look like. And it’s definitely worth trying a few different ideas to see what comes out in practice.
On this specific edit, a few notes:
Remove “New proposed issue found:” from the title. Among other things that makes it easy to see in the list that a human has edited it.
Along the same lines, remove Issuebot’s boilerplate in italics at the top
My idea for the “Cause” part was to give a few, hopefully-not-too-technical explanation for what we know about why this is an issue. Like:
In the first situation, hte upgrade process should have automatically enabled the new WirePlumber session manager, but in some cases it did not. In the second situation, WirePlumber is running correctly, but the older PulseAudio system is also enabled, and this combination does not work.
Then, the actual “what to do about it?” part would go in Workarounds (replacing “none yet”, of course.
Markdown formatting with numbered lists with long paragraphs is hard. If we do want to have issues with combined possible causes (and, yeah, I think it’s worth testing!), maybe it’d be easier and cleaner to, instead of lists, use headings like “Cause (Situation One)” and “Workaround (Situation One)”?
Also, hmmm, as I ook into the https://bodhi.fedoraproject.org/updates/FEDORA-2021-3c4c454c98 update Issuebot linked, its really unclear to me if this update will solve one or both problems, and for whom the problem is solved (like, will it retroactively fix systems, or just prevent new upgrades from being broken)? This may be a case where we need to contact the full QA team and/or the developer to get details. We should also develop a process for that!!!
If all goes well with this experiment, there won’t be a wiki for F36 and forward. Copying the existing wiki entries is really a way for us to look at real examples and consider how they work in this format. And, also, of course, to fill out this category to the point where we can make it open to the public and make it really useful (and a practical demo.)
Ah, you’ve discovered something interesting. It does have the CommonBugs keyword:
Hi all! I made Issuebot a little smarter — it will now give different messages for different types of update messages (candidate to testing, released to stable) in bugzilla.
Everyone in the triage team group should be able to edit those messages, if you see a typo or if the wording should be improved. (We should probably discuss first in the second case, though.)
As you may have noticed, the templates include the strings $BUG_ID and $UPDATE_ID. Those will be replaced. There aren’t any other replacements right now, although theoretically we could create them.
And that’s all for tonight, I think!
Sorry for all the notification noise while I’m working on this. Theoretically when the system is in place and running as planned, updates will be far less frequent — and connected to something actually happening.
No, it is not on purpose. I could pretend it was a clever bug put there for people to spot? But no.
I see you updated a lot of the posts, and commented! Thanks! I’ll take a look and hopefully also get some time to do some of the other ones.
Everyone: if you see posts that seem ready to go, give them a vote. As per the poll above, I’m going to implement the thing to automatically send them out of “Proposed” and into the higher-level category once they get .
Question for all @common-issues-triage — should we close and unlist issues that were resolved during the beta, or should we move them to the Archived Common Issues category?
(Close-and-hide would be the same as the procedure for declined issues. Moving them to the Archive would de-prioritize them in search results but the issue would be more easily found.)
I’ve gone through all the issues @alciregi worked on, and they look great. (Thanks again for doing all that!) I have provided votes to most of them, but the rest of you have not. If you have a chance, can you look and if the issues look good, do so?
I think once that’s underway, we’re ready to open this up to public preview.
I know right now it’s Kind of A Lot All At Once, but that’s becasue we’re converting from an existing process with a lot of issues there already. In real use (like, for upcoming Fedora Linux 36), they should come in at a more manageable rate as the issues are identified.
reaction — if there are, say, three of those from members of the triage team, Issuebot will automatically move them — and also mark all replies, except any from Issuebot itself or any solution, as hidden, so as not to distract.
And you were correct in noticing that something was strange with that bug.