赞！海口70岁老人想无偿捐出房子 出去云游看看世界

In Ubuntu Software Center we have categorized software about as far as we can using .desktop Category values and .deb Section values.

To produce more useful categorization, e.g. "Themes", "Web Servers", "Media Converters", debtags is the obvious candidate. To use them, we need Launchpad to publish the debtags in the first place.

Bug 3945 is sort of a wish for debtags, but also a wish for them in products.

I just looked a bit at this to satisfy my curiosity (at http://wiki.debian.org/Debtags).

The Packages file gains a Tag: field, for example 3dchess has has something like this:

Tag: game::board, game::board:chess, interface::3d, role::program, use::gameplaying, x11::application

The tags are held in a database http://debtags.alioth.debian.org/ssearch.html which raises some questions about any implementation in Launchpad:
 * Is the Debian database the only place we should be including tags from?
 * How often are the tags updated?
 * How up-to-date do the tags need to be in LP?

Once we understand more about where this data originates and its behaviour, adding the tags to Packages.gz is reasonably easy. We can probably import the tags into Launchpad's database which enables other parts of LP to benefit.

Comments about this from mvo:

 * We will need to use the Debian database as an initial import, plus we want to merge it daily
 * We want to edit tags in LP itself
 * Any conflicts with at merge time should prefer the local change

That puts it outside the size of item we can address properly in maintenance. I'm removing it from the escalated bugs list and we'll need to become a stakeholder feature.

I think we could do it as a maintenance thing, if we reframe it.

Syncing with debian isn't an LP core facility: yes its needed, but that doesn't need to be part of LP.

What we need is:
 - support for storing debtags in LP, presumably in a distroseries-sourcepackage or perhaps distro-sourcepackage
 - support for exporting them in Packages.gz

Importing from Debian and applying deltas from debian can be done over the LP API.

The LP dev + ops could take on the gardening of the importer if needed. It would just be a regular script though - no need for it to be part of the LP tree.

I think this makes the LP specific scope much narrower.

(Oh, plus a UI page to edit the tags against whichever context we decided they applied - distro sourcepackage or distroseries sourcepackage).

The UI bits makes it outside the scope of maintenance to me.

This is no longer escalated so no longer critical.