[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Forwarding bugs upstream

On Tue, Jan 11, 2011 at 09:15:41PM -0600, John Goerzen wrote:
> I think it is perfectly fine for a user to submit a bug report to
> the Debian BTS first.  They may not always be equipped to know what
> is a Debian and what is an upstream bug.  And I also think it ought
> to be perfectly valid for the Debian developer to close the bug
> saying it's an upstream issue, together with a pointer to the
> upstream BTS and promise to get involved should there be any
> question about the Debian packaging, environment, etc.

I think this can actually increase the maintainer's burden, since it can
increase the number of duplicate bug reports, since there isn't already
a bug listed as reported.  I generally assume that if a bug is open but
not marked forwarded that it isn't forwarded, and I'm not intrinsically
opposed to this.  Forwarded bugs are better, but if it doesn't happen
immediately, that's okay.

> Now, here's how it proceeds if I have to forward a bug upstream for
> Bacula, which uses Mantis.  Creating a Mantis account takes 30
> seconds, but Mantis won't email reports to people without accounts,
> and the only way to add stuff to it is on the web.

As I've said, I generally don't mind being added to the CC list, and I
think that BTS systems should allow non-subscribers (and subscribers) to
add information via email.  I realize that upstreams tend to use BTSes
that don't do that and therefore make their end users go through a lot
of unnecessary pain.  Also, if the BTS won't CC me when someone responds
to the bug (even with an account), there is zero chance of me reporting
the bug upstream, since I have better things to do with my life than
constantly checking a slew of BTSes.

> I'm adding zero value here.  Zero.  It is a huge and frustrating
> waste of my time.  It is also frustrating for upstream, who would
> rather just talk with the user directly and involve me if they think
> there's a Debian-specific question.  I don't understand why some
> users want it to go this way, but many clearly do despite the fact
> that they get worse service.

I think it depends on the situation.  I've looked at the open and
forwarded bugs reported under this email address and of the 60, there
are at least 47 that I could immediately determine (just by being
reminded of the Subject line) that included a testcase or a patch or
were trivially easy to reproduce (or understand wrt the desired feature
for wishlist requests).  Those are pretty much forward-and-forget.

There are cases where the maintainer cannot appreciably reproduce the
problem (such as with the kernel or X) and then I have to make a
decision whether I want to put up with the bug or forward it upstream
myself.  In these cases, it's usually the former, since I am just not
going to recompile my kernel (which is the Debian one) the ten times
required to bisect the problem.  If there's a new version in
experimental, I will often try that to see if it solves the problem,
though, and report back.

I try to forward bugs upstream when I have the time, especially when I
have a patch, since it may need tweaking with upstream.  But I always
try to put a patch in the Debian BTS, since it is much more likely to be
rapidly fixed in that case.  (#605941 is a great example of this.)

So I think what my position is is this: if the bug is simple, clear, and
easily understandable, then I don't think it's unreasonable for the
maintainer to forward the bug upstream.  Examples that I think fit into
this category:

* (normal) This program produces out-of-range results when I use the
  attached file as input and option -p.
* (wishlist) This program should support W3C specification ABC (as well
  as the currently-supported DEF) with regard to XYZ functionality. 

If it's going to be difficult and require the user and upstream to work
together to solve the problem, then it's okay to say something like, "I
can't reproduce this problem and upstream is not going to be able to fix
it without your help, so would you mind forwarding the bug upstream?"
Giving a reason actually makes me much more likely to comply and less
likely to be irritated.

brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Attachment: signature.asc
Description: Digital signature

Reply to: