On Sun, 2021-11-07 at 15:46 -0500, Matthew Miller wrote: > On Sat, Nov 06, 2021 at 11:55:39PM -0700, Adam Williamson wrote: > > * Acknowledged and had a definite plan to replace the existing tooling > > and practices at least at the same level as currently. > > Okay, cool. Can you help me better define the "at the same level" benchmark? > My stab at things that needed to make sure the new way meshes with the > current process: > > 1. The new process needs to make sure that Bugzilla entries with CommonBugs > keyword are triaged in a timely manner. > 2. When proposed Common Issues* are accepted, the whiteboard field in > Bugzilla is updated. > 3. All accepted entries need to follow a consistent format, ideally using > some form of templating. > 4. We need templates to deal with special cases like those which require > installer images, or where a workaround is needed even when an update is > available. > 5. Entries need to be updated with instructions when a candidate fix is > available. > 6. And further updated when a fix is released. > 7. We figure out something to do about archiving at EOL time. (Although this > doesn't necessarily need to be in place until... F38. Could be part of a > general plan to archive older topics on Ask Fedora.) > 8. We have new documentation covering the new procedures. > 9. We have tooling in place and/or people commited to cover all of the > above. > 10. More automation would be lovely, but at least we don't want it _less_ > automated than the current state. > > Does that cover it? What did I miss. That's more or less it, except that it doesn't cover how update- commonbugs helps a *lot* with points 5 and 6. Doing that manually is a drag. > > > > * Came with people attached who are definitely committed to working on > > the implementation and all the work of writing issues, wrangling > > replies, tagging things, aging things out... > > Definitely have people _interested_. I'll see about _committed_. :) Yeah, see, this is a fairly significant distinction. ;) Honestly, if people are crazy enough for this and you can get to the point where there's a system that will work and just give Kamil and I the user's guide, that would be fine too. I just don't want to get stuck in a bind at F36 Beta time where someone's decided moving common bugs would be a great idea but we have to figure out how to actually do that as we go along. > > I'm not proposing we do this until we hit the appropriate time in the F36 > schedule, so I guess ~ beta freeze. That gives some time to line things up. > Adam, would you be _interested_ in helping update the scripts and creating > automation, if you had work time to do it? What would the tradeoffs be? The prospect doesn't exactly fill me with excitement, honestly, but if nobody else wants to do it yet this is still somehow super desirable, maybe. The tradeoffs would be with all the other stuff I have to do in the pre-F36 Beta time, like proposing criteria changes, updating the openQA packages to recent snapshots, adapting the openQA resultsdb reporting code to handle authentication, making openQA job scheduling handle Bodhi 're-trigger requests' messages once they're fixed, writing new tests for openQA (we have a backlog of test request tickets some of which are over a year old), finally getting somewhere with releasestream... > > Also: although this isn't a change to Fedora Linux... maybe I should run > this through the Changes process? Hmm, I dunno if that'd help or just add bureaucracy, really. > > > * Bikeshedding tangent: I prefer "Common Issues" to "Common Bugs", because > it's broader and there's less potential for conflict between different > possible technical and less-technical definitions of "bug". Like, I'm > seeing some people On The Internet say, with apparent straight faces, that > "bugs" are found during the testing phase and that once it's in > production, it's a "defect" not a "bug". I don't really care a lot. I think the purpose of the page is pretty clear with either title, including the current one. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
