mdz at canonical.com
Thu Apr 27 15:53:59 BST 2006
On Thu, Apr 27, 2006 at 06:34:25PM +0800, James Henstridge wrote:
> Rather than saying that the problem won't be fixed in the context of
> Ubuntu, I think a more appropriate wording is that the Ubuntu task is
> blocked on the upstream task. The problem can't be fixed (or rejected)
> for the Ubuntu package until it gets addressed elsewhere, but it will
> eventually be addressed.
I think that, too, would be somewhat misleading. To say that something is
blocked means that it *can't* be done until a dependent task is completed,
while what we are talking about here is a project management decision to
defer to someone else to do the same work.
> Two ways I can think of to handle this would be:
> 1. a new "blocked" status 2. a "blocked" field for the task, pointing
> at the task that is blocking it.
> Ideally the blocked task would be unblocked automatically when the
> upstream task was moved to a resolved state (rejected or fix released).
> Blocked tasks could be ignored in the default bug listings like resolved
> bugs are (if #1 is used) or as duplicate bugs are (if #2 is used).
This could, of course, potentially be useful in other contexts, as a
replacement for dependencies in Bugzilla.
More information about the ubuntu-devel