[MIR] grilo-plugins

See bug 1116098, where adding grilo-plugins to main has been discussed before. I'd really like to see a split into the plugins we care about in main and the ones we don't. This package currently is a mass of functionality and dependencies (although from universe, it actually only would need dleyna-server, though that has its own set of universe deps).

The Debian maintainer himself commented in the above bug that he'd like to do some sort of split in Debian.

Maybe at least split out the tracker plugin? That would solve the dep problem (dleyna-server is run time dep only) and let us avoid promoting the whole bundle of other plugins to main. Ideally in agreement with the Debian maintainer on package names so that if we do this ahead of Debian, we won't have conflicting names down the road.

Michael,
   Given tracker is in main these days, those specific comments seem obsolete now.

As far as a package split and totem goes, the following plugins would probably need to be in main
bookmarks
filesystem
local-metadata
metadata-store
optical-media

all other plugins are more or less optional but some that may be useful include
youtube
vimeo

most of the remote content on the "channels" tab is provided by
apple-trailers
blip.tv
lua-factory
rai.tv

OK, assigning to Didier for a fresh look.

I've subscribe the debian maintainer in the hope he can split the package

Also, can you ask to drop Recommends: dleyna-server to a suggests? Keep me posted on the outcome of the split that was discussed (I agree with Tim on the plugin split), then please, reassign the bug to me :)

finished to check up the packaging and code source, so apart from the comments above, that will be a +1 for me.

Hello, and thanks for keeping me in the loop!

I think it's a good idea to split the packages. I still haven't had the chance to think about the optimal way to do so, though.

I guess we can follow an approach similar to that of gstreamer and have something like grilo-plugins-0.2-{base,standard,extra} (we would have to come up with some suitable names).

So plugins that don't pull any additional dependency (or very basic ones) would go directly to base, like these ones:

  appletrailers
  bliptv
  filesystem
  gravatar
  jamendo
  lastfm-albumart
  optical-media
  raitv
  shoutcast
  vimeo

What are the dependencies that concern you the most? Tracker?

About downgrading dleyna-server to Suggests, I don't have a strong opinion.

Alberto,
   Tracker is not a problem anymore, the only dependency that is not in main be would dleyna-server.

 Packages in main have much higher requirements, than universe, so I think the concern is really pulling in a mass of random plugins just to get the few plugins required. So from that perspective, it would be good to have -base containing all the plugins really required by GNOME and perhaps a few of the more common/useful services such as youtube (i.e atleast the first 2 sections listed in comment #2). The rest of the the plugins for more obscure services could then go in -extra which would live in universe.

Or another logical way to split might be to have local plugins and web plugins, local would go into main, and at least satisfy the required by GNOME to function.

Are you planning to do the split soon alberto (in debian or ubuntu) or should we be taking it?

From discussions on IRC -base will have:
bookmarks
filesystem
local-metadata
metadata-store
 appletrailers
  bliptv
  filesystem
  gravatar
  jamendo
  lastfm-albumart
  optical-media
  raitv
  shoutcast
  tracker
  youtube
   vimeo

grilo-plugins split has been uploaded now

ack with 0.2.13-3ubuntu3, please upload something depending on it and I'll promote the needed parts.

This MIR bug report says that the ubuntu-gnome team will be subscribed to the bugs. But Ubuntu GNOME is not a Canonical-supported flavor, and the ubuntu-gnome team is not responsible to Canonical for maintenance of packages. I do not think that we can consider ubuntu-gnome an "owning team" for purposes of an MIR.

Perhaps the MIR team could clarify this on <https://wiki.ubuntu.com/UbuntuMainInclusionRequirements>?

@Steve: this should be agreed and written that way then. AFAIK, for things where a canonical team wasn't interesting but an official flavor was depending on, we agreed that trusted flavor would be in charge (or report) critical bugs to us.

In that specific case, should we reject the MIR then? The canonical desktop team wouldn't look for bugs in grilo-plugins if I'm correct and I don't see other Canonical team being interested into it.

I don't think this can be rejected now, its a hard depends from totem which has been updated (and that is essentially owned by the -desktop team). Given that I suspect the -desktop team would take ownership of this MIR?

However this leads to a much bigger issue what happens when flavours need components in main? tracker is a prime example of a package that provides core functionality to the GNOME experience and that no Canonical team is going to look after. It needs to be in main so that nautilus can build against it, so that we get our file seach in the gnome-shell overview.

Admittedly most likely only affects Ubuntu GNOME due to the large overlap with Ubuntu packageset, but still doesn’t seem reasonable to just reject our MIR's based on the fact we are not Canonical. All the packages we have MIR'ed are very well maintained in debian and for the most part syncs, and we work upstream on these, if there is a CVE I can get the upstream maintainers to make a new release with the fix.

@Steve, where is the "Canonical supported" requirement coming from? It's not in the currently MIR documentations/rules and has not been enforced, so it looks like it's not a defined rule at the moment. That might be a discussion worth having though if you think thing should be that way...

The tracker case is quite interesting. It's code which is only conditionally executed on GNOME shell sessions, but has to be in main because the library is linked to nautilus.

It's at least unusual that Canonical might have to support codepaths which can never be executed in our supported environments.

On another note, it will be great that every archive admin members follow the same procedure when promoting a package to main. The bug is still opened and not fixed release, I was not even aware then that it's been promoted already. I don't think I handle that promotion on the 04 of march, which is quite recent (my logs and command doesn't show this). Sad that we don't have in the UI launchpad logs showing who originated the request.

What I personally do when promoting a package is that I tend to copy/paste the promote command output on the bug itself when changing the status. That's also a way to ensure the archive admin checked that a MIR was filled if needed. (I also always separate the "Fix committed/Fix released" in 2 separates steps when I'm handling both in one run). Can we move the archive admin process around this?

I am not asking for this MIR to be rejected, nor am I asking that the desktop team monitor the bug mail. What I am looking for is clarity about who is ultimately responsible for addressing any problems with this package with respect to the main inclusion requirements - including any MIRs that might be required for further future dependencies. This was the intent from my side when we had the discussion that led to listing this as a requirement on the wiki page; I'm sorry if that intent didn't come through clearly.

Logically, I don't think it makes sense for the development team for a universe flavor to be ultimately responsible for a package with respect to main. Would you agree?

FWIW the context for why I care about this is basically <http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html>. It's important to have an escalation path for bugs on packages in main, and I believe it's a bug to have "unowned" packages in main. (I think it's also a bug that lubuntu and xubuntu are considered "owners" on that page, since like ubuntu-gnome they are universe flavors; but note that they each only have one package subscription listed, for a package that is co-owned by the desktop team.)

Anyway, this isn't a problem that's specific to this MIR bug, so I'm happy to take the general discussion to email with the MIR team. Would the desktop team be happy marking ~desktop-packages as a subscriber for grilo and grilo-plugins?

> On another note, it will be great that every archive admin members
> follow the same procedure when promoting a package to main. The
> bug is still opened and not fixed release, I was not even aware then
> that it's been promoted already. I don't think I handle that promotion
> on the 04 of march, which is quite recent (my logs and command
> doesn't show this). Sad that we don't have in the UI launchpad logs
> showing who originated the request.

Yes, agreed on all points. It's clearly incorrect to promote a package to main without updating the bug, and it's very unfortunate that we don't have audit logs to show who promoted the package. I will address this with the archive admin team.

demoted grilo-plugins-0.2-extra, however grilo-plugins-0.2-dbg still depends on extra. I'm demoting that too.

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?

Just a note: grilo itself isn't an issue as per see, but we have multiple examples of those instances I guess throughout the archive (even kubuntu things).

As Steve told, let's focus on the main issue (actually I see many):
1. what to do in similar case where we have a build-dep/dep for build-time requirements where only community flavors are interested in?
2. how to ensure that the strict binary separation are not overlooked in the future? For instance, we have from the tracker source the libs in main, but not the tracker/miner services.
-> The canonical desktop team are ok to "support" the libs, but not the services.
-> What if one day, something starts to recommends/deps on the service. Then, an archive admin runs check-mir on the package and see " * tracker is in universe, but its source tracker is already in main; file an ubuntu-archive bug for promoting the current preferred alternative". The AA will then just promote it, without having the background info that the canonical desktop team didn't want to support the service, and we end up in the same situation.
3. what procedure to require the AA to follow in case of promotion/demotion so that we can get the historical context easily on launchpad?

I thought for #2/#3, the AA is supposed to look up the old MIR bug and read the relevant history. At least, that's the only procedure we can follow with current tools, to my knowledge.

had to add the -dbg package to the extra-excludes in the seeds, depends on the extra package

On Mon, Mar 16, 2015 at 01:59:16PM -0000, Michael Terry wrote:
> 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?

This, in effect, is what the archive reorg spec was about. Unfortunately,
to date it has not been implemented. So no, there's no way to do this
currently.

> 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?

As far as I'm aware this isn't really a commercial support question. From
my POV this is about development support.