Comment 1 for bug 1971973

I’ll review the rest on the MIR, but to not add more delay, I think we should discuss this:

> "- The package does not run an autopkgtest because desktop softwares aren't easy to test in autopkgtest. THe situation isn't a regression compared to gedit which we want ro replace. While it would be nice to get some sort of autopkgtest in place we don't think that should be a blocker to replace gedit."

I see more and more packages telling this "It’s already not tested, or the rest of the stack is not tested, so let’s keep this status quo and not improve it". I kind of disagree with this, and I think the MIR process is the right moment to get things right, or at least, in a better state. Otherwise, things will never improve.

So my suggestion, is really to follow the MIR guidelines, stating that either autopkgtests are provided, or that, if not feasable (which I agree testing GUI is hard on our infra and it doesn’t seem unfortunately there is assigned capacity to get that situation better), "the subscribed team must provide a written test plan in a comment to the MIR bug, and commit to running that test either at each upload of the package or at least once each release cycle. "

I think this latter approach is a mitigation plan, (which won’t protect you though from reverse dependencies to break you, contrary to autopkgtests).
Thoughts?