manifest: set ref to bodhi-updates#104
Conversation
|
LGTM - should we wait for the #102 to merge first and rebase? |
|
unless we are relying something from coreos-pool, should we remove |
+1 - good catch sinny. This is one of our mechanical refs so it should just be pulling from fedora release and bodhi-updates repo. |
|
Yeah, I left it in there (and thought I had mentioned it in the commit message, but only did for the opposite case of |
i think that's going to be a reality for us for a while for a subset of packages (at least until we can automate some interactions and gating in bodhi a bit). My thoughts here are that we'd take the lockfile from the passive stream ( |
E.g. for afterburn.
This is the `bodhi-updates` stream. Drop `fedora-coreos-pool`, enable the modular repos, and most importantly, rename the ref accordingly.
|
Had a chat with @dustymabe, @sinnykumari, and @bgilbert about this. To summarize: we're keeping I've updated the PR to drop |
|
LGTM |
As discussed in coreos#104, we don't actually want the bodhi-updates stream to pull in newer packages from the pool. That said, bodhi-updates also current acts as our lockfile updater in testing-devel, so it's crucial that it keeps working. We're working to decouple that, see: coreos/fedora-coreos-tracker#293 coreos/fedora-coreos-releng-automation#48 But for now, the updates must flow...
As discussed in #104, we don't actually want the bodhi-updates stream to pull in newer packages from the pool. That said, bodhi-updates also current acts as our lockfile updater in testing-devel, so it's crucial that it keeps working. We're working to decouple that, see: coreos/fedora-coreos-tracker#293 coreos/fedora-coreos-releng-automation#48 But for now, the updates must flow...
3 participants
This is the
bodhi-updatesstream. Right now, this is identicalotherwise to
testing-devel, though in the future, the latter shouldonly be sourcing from
coreos-pool, as opposed to the stable repos aswell.