Comment 21 for bug 1394731

Steve, I'll continue to comment on this bug, since grilo is the proximate cause of this discussion.

So you are correct that main implies Canonical support. In the case of a flavor-only package, Canonical presumably doesn't want to depend on a community flavor team, nor does that community flavor team presumably want to be depended on by Canonical in that way.

I think the confusion is partly historical. Back in the day, flavors were much more "in the fold" and Canonical *was* willing to offer support for them (like Kubuntu/GNOME). So having a flavor team look after packages in main wasn't odd.

After Canonical dropped support for Kubuntu/GNOME, they were demoted from main. But there are still shared packages that cause problems like this grilo bug. Where for purely technical/packaging reasons, Canonical gets asked to support a feature they don't use and may end up blocking that feature from being offered in a community flavor. Which neither side is thrilled with.

Is there no way to mark a package in main as 'not supported?' I remember that we have some way to mark a universe package as supported. Can we do the inverse? That would let us promote grilo without putting Canonical on the hook.

In any case, historically the MIR team did not *require* a team looking after the package. Only recently have we started blocking promotion based on that. And even then, we haven't required that the team be from Canonical. Should we loop someone from Canonical's support team in? See how they handle flavor packages like this?