Bugging questions

[Matt Zimmerman]

On Thu, Apr 27, 2006 at 12:16:55PM -0300, Christian Robottom Reis wrote:
> On Thu, Apr 27, 2006 at 07:53:59AM -0700, Matt Zimmerman wrote:
> > 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.
> 
> Well, can you explain further in what way this is a practical problem?

I don't think it is a practical problem, only one of communication.  After
all, we could just as easily use Rejected for practical purposes, but we
want to communicate the right message to the user.

Someone dropped launchpad from the relevant branch of this thread, but Colin
and I are leaning toward "Escalated".

> Here are my considerations:
> 
>     - In practice, ISTM that we are correct in saying the fix is
>       blocked. As soon as a fix is available upstream, we still need to
>       package it, so we're modeling the process correctly.

It depends on our policy for these bugs, I suppose.  In most cases, we won't
commit to packaging the new upstream release only to fix this bug, but will
let it be solved by the normal flow of new releases into Ubuntu (which is
affected by the phases of the release cycle, etc.).  It is very much a
passive activity on our part.

>     - I think it's not as misleading as many possible wordings for
>       "We've decided to let somebody else do it". 

Sure.

>     - We could hide bugs in this state by default in Ubuntu bug
>       listings, or offer specific views in which this did not appear --
>       in particular, in a developer view, because developers can't
>       really work until the task is unblocked.

Likewise regardless of the name (which I think is the main issue here, if no
one objects to a new status).

> The downside to it is that /when/ something happens then it's up to the
> developer to go and alter the status from Blocked to In Progress. But in
> that case, he's going to get an email notification, so it's not like he
> needs to be polling -- just reading bugmail.

Generally, that won't be appropriate.  If the bug is important enough that
we will take explicit action to get it fixed, I expect we would leave the
bug Confirmed in Ubuntu.

> > This could, of  course, potentially be useful in other contexts, as a
> > replacement for dependencies in Bugzilla.
> 
> I think James' solution to this problem is elegant and more generally
> useful. I'd love to replace Needs Info with Blocked: [ on reporter
> feedback ], and I believe we've discussed that before. And I don't
> really think that the fact that it doesn't include the full semantic
> weight of "we will let someone else do the fix" is a showstopper.

I think it is important that we correctly model the workflow between
different projects; after all, that is what we are trying to do here at the
macro level.

The key distinction is that I see the "forwarded" state as a terminal state,
not an intermediate step to In Progress.

> This appears to be orthogonal to Wont Fix Here, by the way.

I'll take your word for it, since I don't have the details of that proposal.

-- 
 - mdz