before Christmas QA started discussing changes in the release blocker process for bugs
that are not media-related (i.e. don't need to be fixed in the generated .iso/.img
files). The conversation is available here:
I took interest in one specific type of such bugs, which are release blockers in one of
the existing stable releases (i.e. Branched-1 or Branched-2). These are usually related to
the upgrade process. We later decided to mark them with AcceptedPreviousRelease flag in
Bugzilla, so I'll call them like this. This email is concerned just with these bugs,
i.e. just one type of the non-media-related blockers. (I want to separate the overall
topic into several separate discussions, so that it's easier to talk about it and we
don't muddy the discussion with too many things at once).
For these AcceptedPreviousRelease blockers, we want to make sure that all of this happens
before we announce Branched release:
a) their updates are pushed to Branched-1 or Branched-2 updates repo
b) the contents of those repos are available to all our users, also considering all caches
and refresh intervals
Ensuring a) is easy and will be tracked by QA and Bodhi as usual, but for b) we will need
help from releng/infra. Since many users upgrade immediately on release day, we really
need to make sure the updates are available for everybody by that time, otherwise a large
portion of our user base will get affected by those blocker bugs. I have tried to
investigate how best to ensure the latest repo contents are available to everyone, and I
described it here:
As the easiest way to achieve this, I suggested we create a new MirrorManager-related tool
which will strip all old metadata from the repo metalink. Dennis from RelEng agreed he
could run such a tool in these circumstances to make sure only latest metadata are
distributed. I suppose the tool could work something like this:
1. A blocker update was pushed to f23-updates on 2015-01-07.
2. Releng will run the tool like this:
$ ./mm-strip-old-metadata --release 23 --repo updates --date 2015-01-07
(This is assuming there is only one push per day, if not, maybe we can have --timestamp
instead of --date).
3. The tool will go through all metalinks for f23-updates (all primary architectures), and
drop each <mm0:alternate> section which has <mm0:timestamp> older than the
provided date (let's say midnight UTC).
4. As a result, end-user machines will only connect to repositories which already serve
the blocker update (have that or newer repo tree).
And now finally the important question - does infrastructure team thinks this is easily
doable, or is there something not accounted for? Is here someone willing to create such a
tool? In December, I talked to Adrian Reber and I got the impression he's a
MirrorManager developer, so that's the only name I know of, but I don't want to
bother anyone directly. Are there more of MM developers? Is anyone willing to help out
Thanks a lot,