On Tue, 1 Dec 2015 07:21:04 -0500 (EST)
Kamil Paral <kparal(a)redhat.com> wrote:
Taking all of this into account, would this be a reasonable idea?
1. At Go/No-Go voting time, all updates which block F-N release but
belong to F-M (M<N) release, must be already pushed stable. If this
is not the case and it's the last blocking issue, selected tasks
(like copying compose trees into appropriate places) can be
performed, and Go/No-Go will be rescheduled to the day and time when
it is expected that those updates will have been pushed.
I think thats not a great idea. It gets back to why we only slip in one
week increments. If say we have a go/no-go on a thursday and the only
thing blocking it is some update thats not pushed stable all the way
yet, we reschedule for friday and if it's not done then we schedule for
saturday? This means everyone has to work extra hours without even
being sure when the release will be. Leaves less time to sync mirrors,
update common bugs, etc etc.
So, the alternative there would be to slip a week to get it pushed, but
some people may find that excessive.
2. We will
create a new mirrormanager script which will go through the specified
metalink(s) and remove all metadata hashes which are older than
Something like that should be pretty easy to do I would think.
(Although I am not a mm developer)
3. If there are such updates as mentioned in
point 1., RelEng will use this script to remove old metadata
alternatives from the metalink, which means only metadata from the
day this update was pushed or newer will be kept. In order to not
increase mirror strain too much, this doesn't need to be used
immediately, but just shortly before the release announcement (so
that mirrors have time to sync latest packages, and the user load is
distributed among more mirrors including those with current-1 or
current-2 trees as long as possible). 4. Once the script is run in
point 3., we can post the release announcement in 6 hours.
I know there still one manual step involved (figuring out in which
push the blocker update was included), but I don't know how to better
solve it, especially if we don't want to wait for too long.
I would be interested in Infra/RelEng feedback for the technical part
of this (CCing Kevin and Dennis). Do you think this is reasonable
solution, or am I completely off the track here? Do you see any
So, looking back, we had the case of that dnf-system-upgrade. Are there
any others in the past, or are we making a bigger than life deal out of
Also, that case could have been solved by dropping the alternates in
metalink as you suggest above at 2 right?
One thing that perhaps we could improve is to somehow note these sorts
of things to releng. I just checked irc logs and I didn't see any
mention of that dnf-system-upgrade plugin update being important until
nov 3rd. Would a tracker ticket help this?