Re: Bug#3253: Pine base64 bug
-----BEGIN PGP SIGNED MESSAGE-----
On 21 Aug 1997, James Troup wrote:
> Santiago Vila Doncel <email@example.com> writes:
> > > No it's not. What pine is doing is *broken* (and -> a bug).
> > This pine "problem" disappear when both users are using a
> > MIME-compliant mailer. I would ask: Who has a broken mailer?, the
> > person who uses pine, or the person who does not use a MIME-aware
> > mailer?
> Excuse me? Are you seriously trying to claim that using a mailer
> which isn't MIME-aware is broken?
No, I'm saying that pine is no more broken than non-MIME mailers.
pine behaviour is perfectly right according to MIME specifications.
If you send a message to a person not having MIME, don't use a MIME
attach. It's that simple.
> > > The upstream authors may disagree but that doesn't make it a) not
> > > broken or b) not a bug or c) a feature request.
> > Not every (bug|feature request) have to be on the bug tracking
> > system.
> Uhh, why not? Surely that is what it's there for?
We are currently using it for feature requests, so we are really making a
bad use of it. But since we don't have a "wish tracking system" yet, this
procedure is better than nothing.
> > This is what I advocate. In pine 3.96L-3, there is a file named
> > /usr/doc/pine/BUGS.Debian
> > explaining the current status, which everybody should read. This
> > file documents the "problem" and should be enough.
> Why not just leave it on the bug tracking system where it belongs? Or
> can I close all my unresolved bugs, and dump them in a file under
If you have already forwarded them a lot of times, and upstream authors
tell you a lot of times they consider it a feature and not a bug, and the
"fix" is not trivial, and the package is not free, and you think yourself
that it is not a bug, yes, I would say it is right to choose the way you
want it to be documented (either the bug system or a file like
> > We have have more important things to do than adding features to
> > non-free packages.
> So prioritize then, don't close bugs you consider "unworthy" in some
Exactly, until we have a better bug tracking system, I don't want
those stupid feature-requests-already-forwarded-a-lot-of-times
to be on my to-do list.
> > The bug tracking system is there to serve us, not the reverse. I
> > have decided to document this problem in the BUGS.Debian file and
> > not in the bug tracking system.
> Woo woo, maybe we should take that approach with dpkg, X and some
> others, we could get that 2000-3000 open bug figures halved in no time
> at all.
Definitely, we need some policy about bug management. Who "owns" the
bugs? May a maintainer and an upstream author have different views about
what is a bug? May the maintainer and another Debian developer have
different point of views? Who should tell us when a bug is a bug?
> > When we had a "feature-request tracking system" this would fit well
> > as a feature request. Until then, this what-ever-you-call-it is much
> > less important than many other bugs and does not worth a place in
> > our bug system.
> This is evil. It is very bad, IMO, to start prioritizing bugs and
> closing ones you feel are less worthy than others. There is nothing
> wrong with 3253 staying in the bug tracking system, in fact this is
> where it should stay until it is dealt with, and documenting it *does
> not* count as dealing with it.
I see it much more like a feature-request than a bug.
This "bug" has reached its "final" state: the bug is dead.
So there is nothing more to "track". Since there is nothing more
to "track", there is no sense in having it in a *tracking* system.
Instead, I would move it to a "dead bug system", if there were one. But
there is not, so we have to ask ourselves: Is a bug *tracking* system a
good place for a *dead* bug? I don't think so.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .