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