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? ...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. ...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. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
