Comment 1 for bug 1869792

Usually we are not doing per-arch decisions, MIR reviews are based on a source package.
But there were excuses in the past - and in this case it is not that much "per arch" even though u-boot-rpi sounds that way.

u-boot-rpi is one of multiple binary packages produced by src:u-boot.

Also these are only built on arm*
 u-boot | 2019.07+dfsg-1ubuntu6 | focal | source
 u-boot | 2019.07+dfsg-1ubuntu6 | focal/universe | armhf
 u-boot-rpi | 2019.07+dfsg-1ubuntu6 | focal/universe | arm64, armhf

And in fact src:u-boot already has an approved MIR at https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/692613.

So we are essentially re-reviewing just the sub-portion of u-boot that is responsible for u-boot-rpi.

Also foundations is already subscribed and maintains this (the changelog history is frequent)
$ ./get-packages-subscribed.py --team foundations-bugs -p | grep -- u-boot
u-boot

So it is actually already as close to main as it can be in terms of:
- maintenance
- src:pkg in main
- usage in RPI boot path

I agree that we should promote the package as well.

d/rules isn't the cleanest I've ever seen, but I'm still waiting to see the rom/bootloader that would be that way.

It has build-time tests and while autopkgtests are hard it is essentially used all over the place on any RPi testing.

The build log looks

None of the typical other checks (python, go, linking, ... apply to this package)

So the addition of u-boot-rpi looks mostly good from a MIR POV.

@David:
- the package appears to get regular updates/fixes by the foundations team
- upstream releases ~quarterly
- it might be too late for the brand new 2020.04~rc4, but what is the reason to not update to 19.10 or 20.01?
- Debian has 20.01 in testing and 20.04 in testing, so their speed is fast
- Is there an active maintenance and update policy in place or is it randomly updated as needed?
- sometimes packages tend to be outdated by accruing to much delta that is hard to rebase&maintain; It seems the packaging was split mid last year on 2019.04+dfsg-2ubuntu1 and not rebase d since then. Might I ask about how well upstreaming to Debian works (links to some examples would be nice). I'd wan't to avoid that this package seems to be "ok now" but we can expect it to rot away for the reasons that inhibit regular maintenance mentioned above.

To be clear I don't request to do these updates for Focal (it is too late), but I'd want to see some reassurance that this is under control and e.g. will get a rebase soon once 20.10 opens.

Marking incomplete until this is clarified.

Note:
If the above is ok (I assume it will be) we can hand over to security since the old bug had no explicit security check as far as I can see and as you outlined other binary packages of the same source have known CVEs I'd want security to:
a) review for u-boot-rpi
b) state that it is ok to add this to main with known CVEs in other binaries of the package (not that this might e.g. break their CVE tracking)