On Fri, 2017-01-06 at 09:23 -0200, Eriberto Mota wrote: > Nop. Paulo used the right way. I will explain. > > The previous upload was to experimental. As we know, the experimental > is parallel to unstable/testing/stable. So, the right way is close in > unstable, not in experimental, except for special situations. Closing > a bug in experimental won't solve the problem for final user. Consider > that some unfaithful person could upload to experimental and... > disappear. Well, the bug will be closed in experimental but never > solved for final users.
Sounds like neither of you understand how the BTS does version tracking. It follows the debian/changelog entries and where they diverge etc, forming the graph image you see on every bug entry. So closing a bug in experimental only means it is closed in experimental only, it will remain open in unstable. If you then add another changelog entry to the experimental version and upload that to unstable, it knows the unstable version is derived from the experimental version and that therefore the bug is now fixed in the unstable version too. If you then make a few uploads to unstable and accidentally reintroduce the bug after the stable release and then make an upload fixing it to experimental, you can mark the place where you reintroduced the bug and the BTS will know that the bug is fixed in stable, unfixed in testing/unstable and fixed in experimental. It really is very sophisticated and I haven't seen anything like it elsewhere. Theoretically Github could do it but I don't think they do. -- bye, pabs https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
