Unity System Compositor has two unsynced bug lists

This is a known issue. We aim to track upstream bugs in:
   https://bugs.launchpad.net/unity-system-compositor
and distro bugs in:
   https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor

All bugs should usually at least be logged in the former. Where there are discrepancies the bug maintainer(s) should be adding additional tasks. We do this well for the Mir project, but USC lacks the same level of personal ownership and monitoring of bug traffic. I try to do it myself but obviously miss some things.

Lacking ownership and official release management of USC it might make sense to only have one bug list. But ideally I'd like to retain both.

I understand the theory of the multiple bug lists: I was a Launchpad developer 2005~2008. The idea was that by tracking upstream and distribution bugs separately, the developers of one could easily see when the developers of the other had fixed a bug they shared, and merge or cherry-pick the fix as appropriate. And that the benefits of doing this would outweigh the costs of misfiling and misprioritization caused by multiple bug lists with multiple importance levels and assignees.

But with unity-system-compositor you don't *have* multiple distributions with developers who ever fix bugs independently from upstream. (unity-system-compositor isn't even in Debian!) Maybe someday that will change. But right now, keeping separate lists inflicts all the costs and none of the benefits.

I understand the intention and it's wonderful. I remember proposing multi-dimensional bug tracking/tasks in a former job for similar reasons (multiple supported releases and multiple vendor variants of a single product).

Although even with a single distro you still need separate bug tasks. That clearly delineates a bug fix that exists upstream from one that has made it into a package release. And in Mir we have an additional use: A bug that exists in "Mir" might be Invalid in Ubuntu if it was regressed, found and fixed all within a single cycle.

You only need one motivated bug triager to keep things up to date. The Mir project has that, but sadly USC does not. I feel I will care about this in the future and when that happens I'll end up being the maintainer for USC bugs. But until then, *shrug*.

I'll drop this now, but notice that again you are describing the classification, and not describing any benefit of the classification. You can classify bugs in all sorts of ways, and whether a bug reached a package release is just one of those. But any classification that does not have a tangible benefit -- any classification that does not help developers prioritize their work -- is a waste of time. It's a waste of reporters' time in reporting undetected duplicates, triagers' time in maintaining the classification, and engineers' time in sometimes working on the wrong things.

Having cleanly classified bugs has helped me to work efficiently for several years now. It does in fact help developers to do their work.

In the Mir example again, on several occasions in recent history it was only due to multiple accurately maintained bug tasks that developers were made aware of the fact that they had backported a fix to some maintenance series but forgot to ever land the fix on trunk. In each case this mistake was only discovered because the multiple bug tasks were being well maintained.

Even in unity-system-compositor, we do have multiple different branches with different contents:
  Trunk: lp:unity-system-compositor (https://code.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk)
  Ubuntu: lp:unity-system-compositor/ubuntu (https://code.launchpad.net/~unity-system-compositor-team/unity-system-compositor/ubuntu)
So if the contents of those two branches are different, each branch potentially needs a different status for any given bug.