Re: When a bug is a bug?
Santiago Vila writes ("When a bug is a bug?"):
> I have a great difficulty in convincing the Debian octave maintainer that
> Bug #20561 is a bug. I have explained him in great detail why it is a bug
> but he still says it is not and even *refuses* to discuss about it.
Dirk (as octave maintainer), are you on debian-policy, or do you want
CCs of this discussion ?
There are two kinds of response to this posting by Santiago. One is
to do with the specific case, and the other is to lay down some
general procedural guidelines.
In this posting I will deal only with the former. I will post
separately to debian-policy with regard to the latter.
There are a number of things I would like to observe:
1. Santiago initially mailed owner@bugs about this matter, and didn't
go away when Guy told him to. He did when I referred him here. (At
this point neither Guy nor I entered into the details of the
situation, after having determined that it was nothing to do with us
as bug database admins).
2. There are two issues being confused here. One is the behaviour of
with respect to files in the future, and the other is the search path
ordering. There should be two bug reports.
3. We generally have a rule that says package maintainers get to make
decisions about their packages. This is not universally applied, and
is not yet formal - for example, certain bugs have been left open as
wishlist items against the wishes of maintainers.
With respect to the technical issues, I feel that:
1. The search path misfeature is already known about by the upstream
authors. Since the upstream authors feel it is a bug we should
probably do so too (though this is up to Dirk, really - he may feel
that it is not a bug or misfeature and should not be changed, though
it seems unlikely). All bugs, whether known about by upstream authors
or not, belong in our bug system. Therefore, this bug should remain
open but forwarded, at severity normal or wishlist.
2. The timestamp problem: I don't see a compelling reason why a
program should be expected to behave in any particular way when
confronted with files in the future. It may be a desirable feature to
one user, but the author or maintainer may not feel that it is an
appropriate addition to the program. Therefore, I feel that this is
wholly within the author and maintainer's jurisdictions. If the
maintainer feels that it would be useful to have this feature but that
it's not a bug then they should leave the report open as a wishlist
item - this indicates, for example, that they would accept a good
patch. If the maintainer feels that the feature is ultra vires for
the program then they would not accept a patch; they should say so,
and close the report.
Ian.
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: