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

Re: Bug#3253: Pine base64 bug

I have been listening to this long winded thread and trying my best not to
comment. Obviously I have failed ;-)

There are two issues I would like to address. One is this bug in
particular. The other is current use of the bug tracking system.

Santiago should know that Ian is not going to let this issue die. As a
former maintainer of the pine package, I had to put up with this same bug
report from Ian. I did my job and reported it to the author. The report
back was then, as it is now: This is the way that mime attatchements are
designed to work in Pine.

Ian, and those who agree with him, is not going to change his mind as to
the buggy nature of Pine in this reguard because he refuses to admit that
there might be a reason to base-64 encode "plain" text. The pine author,
on the other hand, sees this as the choice of the user.

What is broken behaviour is the use of a Pine attatchement when all you
wish to send is plain text that could reside in the message body. The
product works exactly as advertised, and that functionality can be used,
or not, as is appropriate. The correct method for including plain text in
your e-mail is 'CNTRL R' which lets you read a text file into the body of
your message. (no MIME encoding there)

It is no more "broken" to allow "unnecessary" encoding, that can't be
viewed by a non-MIME complient mail reader, than it is to encode a binary
file as a MIME attatchement. The binary is no more accessable to a
non-MIME complient package than the text file attatchement.

About bugs in general:

When a user reports a bug that the package maintainer can't deal with, the
proper proceedure is for the maintainer to talk to the upstream maintainer
(often the original author). When the upstream declares this to be a
non-bug there is not much more the maintainer can do. Fixing the local
version is not necessarily an option, even when the fix is well
understood. Making modifications that significantly change functionality
bring Debian "out of step" with that product from other vendors...not

It was my understanding that one reason sufficient for closing a bug was
its forwarding to the upstream maintainer. Placing the package maintainer
between the author and a user in a battle that neither side is willing to
loose does nothing more than abuse the package maintainer to no good

While, in the past, it has been OK to have a bug in the tracking system
indefinately, bugs older than a particular age generate NAG e-mail to the
package maintainer. This is clearly intended to give the maintainer an
incentive to close the bug. Use of the bug tracking system for public
notification of disputes between users and package authors is not a good
use of this medium.

Ian, why is it not sufficient that disputes such as yours with Pine be
documented in the package's README file? Why is it necessary to occupy the
maintainer's attention with this issue "for as long as you both shall

Waiting is,

_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: