Directing submitter to use upstream channels instead

[Bjorn Tillenius]

On Mon, Feb 06, 2006 at 04:45:50PM +0000, Ian Jackson wrote:
> Sometimes I have this situation:
> 
> I want to close a bug report against Ubuntu, despite the fact that I
> agree that the report describes is a defect in the system, because I
> don't think that Ubuntu is the appropriate forum for resolving it.
> This might be because there are design issues involved, or more
> substantial implementation effort would be needed, so that we don't
> have the resources to fix it.

OK, I would say it that strictly closing the report is not the right
thing to do in Malone. Malone has the feature that the same bug can
exist in more than one place. So for a bug that's not best resolved in
Ubuntu, you would add a link to the upstream bug tracker. That way,
people can see that the bug has been reported in Ubuntu, and that it's
being worked on in the upstream bug tracker. And when the upstream bug
is closed, the Ubuntu bug's subscribers get notified about.

This hasn't all yet been implemented yet in Malone, but I'm currently
working on it, so it's a good thing you brought it up for discussion.
Not everything has been speced yet, how it should work, for example bugs
like the one above you probably don't want to see in you bug listing
while working on Ubuntu bugs, but maybe there are cases where the bug
has been reported in the upstream bug tracker, but you still want to
fix it in Ubuntu, and the push the fix upstream.

> Sometimes the issue seems worth my effort reporting the bug upstream
> myself.  This typically involves a relatively thorough search of the
> upstream bug system, and a redaction, rewording and restatement of the
> report; it also puts me in the contact loop for future updates from
> upstream.

So here I would add that you should link the Ubuntu bug to the upstream
one. Then not only you would be in the contact loop, all the bug's
subscribers would be able to see status changes of the upstream bug.


> Other times I would prefer not to (perhaps it seems very likely to me
> that the issue is already known about upstream, or that it is a matter
> of opinion and the original submitter is better placed to advocate for
> their favoured solution, or the issue is too unimportant compared to
> the amount of effort required).
> 
> In these cases in the Debian BTS I would normally close the bug with
> an explanation to the submitter.  In Bugzilla I would explain my
> position and set the status to NOTFORUS.  What should I do in Malone ?
> 
> I asked this question on #launchpad and it was suggested that for now
> I should use `rejected', but I was asked to raise the issue here so
> that we can discuss it more generally.
> 
> IMO `rejected' is wrong because it implies that the original report is
> somehow defective.  It is a (relatively mild) implied criticism of the
> submitter's decision to file the bug in the first place.  Sometimes
> this is appropriate, and that's when `rejected' is right.  `Rejected'
> to me means `this should not have been filed in the first place and
> the submitter should have known that', and rejecting a bug in this way
> (with a polite explanation) is part of the process of educating the
> community.
> 
> However in this case the situation is quite different.  The bug report
> is quite true and appropriate, and no criticism of the submitter is
> implied by my decision to spend our limited effort elsewhere.  It
> would be nice to be able to close a report (strictly, in LP-speak, a
> task) with something along the lines of `we agree that this would be
> nice but we are not going to spend any effort on it in the context of
> Ubuntu'.

I agree, 'rejected' seems wrong for this case. We'll discuss this at the
Launchpad developer meeting later on today, but I will give my view on
the problem here.

If it's indeed a bug, I think it's fair to let the bug be open in
Ubuntu. Even though it's such a bug that it won't be resolved in an
Ubuntu context, it still exists in Ubuntu. Would maybe the following
work?

    * Tell the reporter that he should report the bug upstream, and
      then add the link to the Ubuntu bug report

    * Mark the bug as 'needs info' until the upstream bug link has been
      added

    * Maybe also setting the priority to low, to indicate that this bug
      will be fixed in Ubuntu, only if upstream fixes it.

That way, for a bug reporter, searching for existing bug reports, he
would see that the bug has already been reported in Ubuntu, and is
being worked on upstream. For you, who want to resolve Ubuntu bugs, you
could filter out all the bugs that are linked to an open upstream bug.

Regards,

Bjorn