Re: When to get the upstream maintainer involved.
How about something like:
It is important to realize that your interactions with the
upstream maintainer reflects not only on you as a person but also
upon the Debian project. Therefore some care is needed. In
particular this means that you should:
* be polite.
* do your best to verify the bug. Communicate with the original
reporter if necessary.
* do your best to construct a simple way of reproducing the
problem. Get the original reporter to help if necessary.
[my own personal favourite experience from work was a user who
reported a gcc problem that showed up towards the end of
compiling xpilot]
* do your best to find out what is wrong. Try using a debugger or
strace. You may not be able to solve the problem, but you should
give it a try.
* make a honest effort to find out if the problem is already
known. Take a look at the documentation, the changelog or even
comments in the code.
* pay carefull attention to how the upstream maintainer reacts to
your reports. Some like all the feedback they can get, others do
not. Don't keep on doing things the upstream maintainer seems to
dislike. If you discover something (good or bad), consider
writing a note about somewhere in the debian/ directory, as this
may help others taking over the package, but be diplomatic!
---------------------------+--------------------------------------------------
Christian Lynbech | Computer Science Department, University of Aarhus
Office: R0.32 | Ny Munkegade, Building 540, DK-8000 Aarhus C
Phone: +45 8942 3218 | lynbech@daimi.aau.dk -- www.daimi.aau.dk/~lynbech
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- petonic@hal.com (Michael A. Petonic)
Reply to: