Paul Gevers wrote: > I think as a power user of the BTS such as you, you should know > how to view the information you want.
The power user argument is two-way so I'm not sure that it's a good argument here. You tell me that I have the tools to view the information I want, and yes, I could do that. But the same thing we could say to Sebastian. He's a Release Manager and he is also supposed to know how to get the information he wants. But I will respect his choice as maintainer. Paul Gevers wrote: > > So: I have to call those who advocate for marking bugs fixed in > > experimental as "closed" in the BTS and I invite you to answer the > > following simple question: Where in earth is stated that version > > tracking *mandates* such thing? > > The default behavior of our archive is that if you add a "Closes: #bug" to > your changelog, that the bug is closed. I consider that "documentation by > code" and long standing tradition. That's just a default. Such default is useful because most of the time you only want to fix the bug in a single distribution, usually unstable. But it's not documented that you have to accept such default blindly in each and every case. We are human beings, not machines, and in some cases our needs may differ from those defaults. If we are going to use the "tradition" argument, it's also a long standing tradition to change things when their default values do not suit our needs. > > If you can't quote an official document which clearly states that bugs > > fixed in experimental *must* be kept closed even if unstable is still > > affected, then please admit at least that this is a personal > > preference of yours, and please stop suggesting that it's a > > consequence of version tracking when it's not, and stop telling people > > that they have to do it that way "because of version tracking". > > https://www.debian.org/Bugs/Developer says > """ > Debian bug reports should be closed when the problem is fixed. [...] Sorry for not quoting more text, but the above is indeed my point when we are dealing with FTBFS bugs: The report should be closed when the problem is fixed. If the problem is that "some package FTBFS in unstable", it should be closed when the problem is fixed, i.e. when there is a package available in unstable fixing the FTBFS issue. Similarly, if the problem is "some package FTBFS in stable", it should be closed when there is a fixed package in stable. If we insist that "the problem" is something vague, generic, and not tied to any specific distribution, not even unstable by default, I would be forced to be ultra-specific when writing the subject line to avoid FTBFS bugs being closed prematurely. For example, I could not write "package FTBFS: whatever happens to package" anymore, I would be forced to write "package FTBFS in UNSTABLE", so that it's clear that I'm not reporting the problem in a generic sense, but instead a problem in a very specific distribution (unstable). I really hope that's not what we want, because, again, we are human beings, not machines. > [...]> and later > > """ > Where applicable, please supply a Version line in the pseudo-header of your > message when closing a bug, so that the bug tracking system knows which > releases of the package contain the fix. > """ > > This doesn't imply it must be kept closed, but it also suggests it's fine to > keep it closed. If the maintainer of a package asks you to leave bugs closed > that are closed by uploads to experimental, I think that they are entitled > to do that. And that's exactly what I'm doing here in libplacebo from the very beginning... > instead of imposing your view on others ... and therefore I think it would be unfair to characterize the problem as "me imposing my view on others", as I never changed the open/closed status of the libplacebo bug. I will respect the maintainer wishes on this. But there is still a potential problem: Will other people, NOT the maintainers, also try not to impose their view on me when I report a *new* bug? I ask because I still have to report some FTBFS bugs in oldstable and stable which I found after the recent point releases, and I believe those bugs should be open to signal that they need a fix in oldstable/stable (i.e. there is work to do), of course with the fixed version in unstable when appropriate. Do I need to add some kind of disclaimer to such bugs? Thanks.