end-of-cycle unexpected changes

[setharnold]

The case of https://bugs.launchpad.net/ubuntu/+source/python-boto3/+bug/2061217 is unfortunate -- an old, unmaintained package was only selected for replacement after beta freeze. This causes a rushed hand-waving promotion, without adequate time for review or deliberation.

We need a better way to identify dead packages with obvious replacements before the last week.

[eslerm]

This was also the case for the end of the Mantic cycle and resulted in #41

Perhaps a hard deadline is needed.

edit: 2024-04-29

It was recently discovered that the end-of-cycle requests for qrtr and protection-domain-mapper in Mantic (#41) are causing arm64 issues.

Please see https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2062667

These MIR requests came two days before Mantic's release. It was agreed that these packages would only be used for x13s hardware enablement. Instead, they were added to ubuntu-meta as recommended installs for ubuntu-desktop/ubuntu-desktop-minimal.

[cpaelzer]

For the concrete case, we I have brought this up and we will resolve the nimbus of ownership of simplestreams that caused this (thanks to CPC).

For the generic issue we would wish for some automation (nothing great came to our mind sadly, there are too many metrics for project health to code it up easily) or process (could be a release schedule entry "check all your team is subscribed to for maintainability"). A great input to that might be a tool to create a list "things in main not changing upstream release since last release". Related to that could also be spec CT002.

So far for good ideas, but this needs an owner to ever make progress :-/
Volunteers let us know.

[slyon]

CC @kewisch

[cpaelzer]

Leaving some comments for the current state of this as follow up to the MIR team meeting:

• As mentioned before, the concrete case of simplestreams ownership has been addressed
• The general issue of some things being old and/or forgotten and then popping up too late isn't solved. But right now we lack a system to detect that or resourced to improve significantly.

We will take the freedom to ping teams via bug reports on packages if we get aware of such cases. Since they are in main the owning team should have a triage process that picks this up. This is more effective than establishing e.g. a new tag as many others would need to be made aware of the tag. Bugs should work just fine.

Sadly we feel unable to do more about this right now, but this can be re-opened if there is a change to the resources, tooling or priority going into this.