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

Re: Forwarding bugs upstream

On 01/12/2011 09:35 AM, Gunnar Wolf wrote:
Ben Finney dijo [Wed, Jan 12, 2011 at 04:01:46PM +1100]:
I'm adding zero value here. Zero. It is a huge and frustrating waste
of my time.

Not in my view. I appreciate the Debian package maintainer acting in the
interest of “lower the barrier for each Debian user of this package to
report useful bug information”.

To be clear: Thank you for the time you spend doing this, and the same
to any other Debian maintainer who does unromantic work to keep the
good information flowing.

You are clearly adding value, you will probably word the user's
request in a better way, you will know the library versions and
settings the package was compiled with, the way it is installed,
etc. You will probably forward only some relevant bits - We as package
maintainers should bridge between a nontechnical user and the upstream
developers. Of course, if your bug report was initially submitted by a

Those are some valid points, probably more valid for many packages than Bacula (for reasons I'll get into later).

But still, let's say that a Debian developer has X minutes to spend on Debian a day. What kinds of tasks that the developer does will add the most value to Free Software or benefit the most people to the greatest degree?

 * Working on Debian packaging

 * Fixing bugs that are within their scope/ability

 * Working on documentation

 * Cut-and-paste monkey with upstream BTSs

I suggest that the last item provides the least value. If we realize that it is displacing time that Debian developers could be spending on things that benefit Free Software more, and frankly they are likely to enjoy more, it's a disturbing picture.

Some of what you've suggested above could be accomplished by the DD telling the user, "Here, include this info in your bug report and get me back in the loop if you need me."

This is a special case of more general communication problems. It is rarely a good idea to have a gatekeeper in place between people that are capable of communicating already.

If the user is not capable of producing cogent answers and a useful bug report, even when asked for specific details, this user is unlikely to produce a useful bug report for upstream. But the user is also unlikely to produce a useful bug report for Debian. I don't see my task as a maintainer to provide education to the user on how to read standard logfiles, use the command line (when relevant), etc.

This is a particular problem with Bacula. There are many users that are unable to distinguish between a configuration mistake or misunderstanding on their part and a bug. I imagine this phenomenon exists in any sufficiently complex package that takes users out of their existing comfort zone. If it's clear to me that it's not a bug, I'll of course close it and point them to the Bacula users mailing list. Sometimes it is unclear immediately whether they have discovered a bug or not, but it is quite clear that they don't understand how to configure Bacula and would need a tremendous amount of handholding to get to the point where we know if there's even a bug or not. Again I try to push these to bacula-users. If someone asks me a question I know the answer to off the top of my head, I'll answer, but I never promised to provide free tech support by maintaining Bacula ;-)

-- John

Reply to: