On Wed, 2021-01-13 at 13:42 -0800, Kevin Fenzi wrote: > I'm definitely in favor of this effort. ;) > > A few questions inline... > > On Wed, Jan 13, 2021 at 09:53:36AM -0800, Adam Williamson wrote: > ...snip... > > > > that is all it does. The "releases" and "events" are entirely > > arbitrary; a "release" can be any string, and so can the "state" for a > > given "event". An "event" is defined as a state being either reached or > > left; any number of events for the same state can be present for a > > release. > > Might it be good to standardize these? I mean we don't want to have: > > state: "Fedora 34 Beta Released to mirrors" > and then in f35 cycle: > state: "f35b released/mirrors" > > Or at least record somewhere in a doc what we want to use after the > first cycle in use? I was following the lessons we learned with taskotron: make the tool simple and flexible, standardize the usage by convention. (This also means the tool is flexible: if it works out for Fedora, it could be used for...pretty much any other software project that has this issue). Typically submissions should be done by code or at least scripted, and there shouldn't be *too* many systems submitting events, so it should be relatively easy to make sure they follow the same names. But yes, we definitely want everything that submits to call the same release the same thing :) We *could* write a "fedora helper" for submitting events that enforces a house style, but for something this simple I'm not sure it's worthwhile. We could use one of the name formats Bodhi has, or we could use the 'dist' / 'short' names from productmd compose metadata, I guess. > ...snip... > > > > My idea for using this is basically that we deploy an 'official' > > releasestream instance in infra, and then find things that do the > > actual work of moving Fedora releases into and out of given "states" > > and tack on a bit at the end to tell releasestream about it. So when > > e.g. Mohan is putting Fedora 34 into the Beta freeze, we would add a > > "submit 'enter freeze' event to releasestream" to that process somehow > > - ideally something that has to be run as part of the process anyway > > would send the POST, but in a pinch a human could do it too. When > > Fedora 34 is being 'released', we tweak that process to include sending > > a releasestream event POST. And so on. > > I see right now this keeps the state/messages in a file store? > I think this is a great app to just run in openshift, but if we do that > I wouldn't want to loose state, so perhaps we store things in a > database? I know thats overkill for this simple stuff, but it would mean > we have everything easily stored/backed up, etc. I guess we could also > just make a persistent volume and make sure to back it up. Yeah, it could be a database too, I guess, I just used a text file because it was easy, honestly, and it also means you can hand edit stuff quite easily (this would allow fixups for incorrect names, and it'd also make it easy to 'reconstruct' historical schedules, which I might do at some point). If you file a ticket for adding db support I'll look at it. > ...snip... > > > > > So, what do folks think? Does this seem like a good idea? Should I go > > ahead with trying to get it deployed and onboard things to it? Any > > comments, ideas, potential problems? Thanks! > > Yeah, I like it and definitely think it's worth a try! > > Thanks for implementing it. Thanks for the feedback! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
