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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
