Re: The pine base64 bug - policy
Hi,
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
Ian> My definition of a bug would be something that is not as it
Ian> *should* be, where should is according to technical merit, our
Ian> policies, &c.
Quite. However, your definition of what the behavious *should*
be may not match what other people may have to say about it. Iff
there is a consensus, then we have no problem. If there is even a
significant majority, we may ride roughshod over the minority, and
accept the majority determination of proper behaviour. If, however,
people are roughly split down the middle, as seems to be the case
here, then we are in murky waters.
Ian> If we are to have an argument about what the behaviour of pine
Ian> ought to be then we ought to do so, CC'ing the relevant bug
Ian> report, until we have reached consensus about what ought to be
Ian> done or it can't be resolved.
We have been doing this for what seems like months now, to no
avail. And I do not think that resolution of the pine issue is
suitable for a fiat fix anyway.
Ian> However, the fact that this is a non-free package, that the
Ian> upstream authors disagree, that the bug could be documented or
Ian> that it's hard to fix do _not_ mean that the program is as it
Ian> ought to be.
If I thought the behaviour was indeed a bug, I would agree
with you here. But ...
Ian> The upstream authors are not always right, and we should feel
Ian> free to question their decisions.
If an author has decided to implement a feature that some
people do not like, and further states that the feature is intended,
then I think they have a right to have *their* code work as they
wish. (this in, in my opinion, akin to their selection of sopyright
policy). Ifwe change the software to work in a manner which is
against the wish of the authors, I think ethically we should fork a
branch of development and call it something else (debian-pine).
Ian> Non-free packages can have bugs, and in Pine's case we can ship a
Ian> change if we want to
.
If we agree it is a bug.
Ian> Documenting a bug does not make it not a bug; hopefully we can
Ian> all agree on that ?
Put that way, there is nothing we can say against that
statement. How about: If we dislike a program, or it's features, we
can't just arbitrarily call it a bug. If we can, how many of you are
willing to join me in calling vi a bug? (or emacs, if your editor
choices run contrarywise?)
Ian> For example, several people have complained about dpkg-source's
Ian> behaviour when it packs up an existing foo-n.nn.orig directory
Ian> into a .orig.tar.gz and removes the directory. I happen to feel
Ian> that this is the sensible default, and we have had arguments
Ian> about it, but the fact that this default behaviour is documented
Ian> would not in itself justify it.
Had you stubbornly stuck to your guns, we would have to
reluctantly create a new program that worked as the majority
wanted. I think we should have let you retain the debian-source
package exactly as you wanted it.
Ian> The fact that the upstream authors have been informed about this
Ian> bug means that it should be marked `forwarded'. This will stop
Ian> the nag messages.
That *is* a nice cop-out available in this particular case.
manoj
--
Man shall never reach his full capacity while chained to the
earth. We must take wing and conquer the heavens. -- Icarus
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
--
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: