Comment 13 for bug 1980239

> For the first time, I made failures in the build tests for most of gstreamer
> fail the build for amd64 & arm64. I did this to try to better comply
> with the SRU guidelines.

I appreciate this; it's not required by any means but it is a welcome improvement.

> There is longstanding precedent for gstreamer microreleases to be
> accepted as SRUs and I don't think those have claimed they were being
> done as a GNOME dependency.

This, however, is not persuasive to me. I don't consider "precedent" to be a reason not to follow the SRU procedure. If the other SRU team members who accepted those SRUs want to explain why they think an exception should be made here, that's fine, and then we can document it for the future. Without having talked to them first, however, my /suspicion/ is that they were regarding this as covered by the GNOME exception because of the difficulty we've had pinning down what is or isn't meant to be covered by it.

> I think this gstreamer-editing-services-1.0 update is worth a
> microrelease SRU. I would need to beg upstream for a test case
> since they didn't provide enough details in their commit messages
> & merge proposals.

That seems reasonable - please do get a test case for it.

> I am ok with gst-python1.0 being rejected since the change is unimportant.

Ok, I'll go ahead and do that.

> Gstreamer has a solid record of stability

I find I have to balance this against the fact that they have explicitly partitioned the codec drivers upstream into different levels of support, and the ones we're talking about here are not part of the GNOME core.

> Is that acceptable or should we do another upload cherrypicking
> the one fix we really care about?

Given that there are no test cases and the possible effects of the changes are not obvious, please cherry-pick the one fix in order to get this through into .1.