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.
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: /code.launchpad .net/~unity- system- compositor- team/unity- system- compositor/ trunk) /code.launchpad .net/~unity- system- compositor- team/unity- system- compositor/ ubuntu)
Trunk: lp:unity-system-compositor (https:/
Ubuntu: lp:unity-system-compositor/ubuntu (https:/
So if the contents of those two branches are different, each branch potentially needs a different status for any given bug.