Matthias: concerns about how arch qual happens; about how participation happens
Delegate qual to some other team if there isn't time?

Port metrics agreed in Montreal but no practical progress
Laid-back approach to qual in buster cycle but we would react if there was a real issue?
Emilio was spreading out binnmu scheduling on mipsen because they can't keep up,
discovered during boost transition
Lesson: if issues are unsustainable people need to know - contact release, be proactive

Matthias gets fed up caring for mipsen toolchain issues and reporting things to the
appropriate places. What are the toolchain/porter responsibilities?
mipself is a primrary upstream gcc platform but only the bare minimum; there is effectively no upstream
for the various ports of it we have so testing is basically only done in Debian
Ivo: porters can ask toolchain for help but toolchain should be able to say "no"

In buster cycle Matthias raised issues twice but had no response or no progress
Release need to meet him half way on that

How long is reasonable to wait before uploading toolchain to unstable knowing an arch
will break? 28 days is too long for Matthias to discover issues. Breaking the arch
then blocks things up anyway e.g. transitions because of build failures
Porters should be keeping up with toolchain but no deadline: will a deadline notification
help to provoke porter action?
Matthias should not feel responsible for carrying a port - it's reasonable to expect
ports to pull their weight too in testing and fixes

ACTION? Matthias to notify gcc list of an upload to experimental and
a date he will upload to unstable


When ports are dropped or demoted the timeline is always short. Ports has a lot
of manual work to get set up there which takes time, so there is no overlap.
Can ports have a full dak and a testing suite and migrations? Issues with keeping 
things in sync and with people to do that work

Arch qual happens too late in the cycle - too late even to start talking about it,
let alone doing it
Do regular qualifications with requirements to fix things before the next checkin?
Only plausible if we have non-subjective requirements - could be done even so,
as long as ports are treated equally