Re: Forwarding bugs upstream
brian m. carlson writes ("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, [...]
If the maintainer agrees with you then they will be happy to deal with
the bug report the way you want. But I think this should be up to the
maintainer to decide.
> 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.
That is up to you.
If you report the bug to the Debian BTS but neither you nor the Debian
maintainer want to do the make-work of dealing with upstream's tedious
BTS, then the bug will sit in Debian's BTS tagged "should go upstream"
I don't think it is up to you to say that this is the maintainer's
problem and that they must do something about it. If it bothers you,
you should yourself do the work to improve matters.
> 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.
If you think the work of forwarding bugs upstream is so important and
useful - more important and useful than the work that you are
currently doing - then perhaps you would like to take on that role for
some existing maintainers who don't have the time, or who feel that it
isn't tha valuable ?
> 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:
I think it is always reasonable for the maintainer to forward the bug
But what I think is bad is _demanding_ or _requiring_ the maintainer
to forward the bug upstream. If they don't want to do that for
whatever reason then asking the submitter to do so is IMO perfectly