On Mon, 08 Jan 2018, Ian Jackson wrote: > My package has a mergeing history, and bugs.debian.org has become > confused. > > The real history is like this:
[...] > When I look at my changelogs, I have not been consistent about the > ordering of entries when I make a merge. > > The result in the BTS is this: > > https://www.chiark.greenend.org.uk/~ijackson/2018/bts-merges/graph.png > https://www.chiark.greenend.org.uk/~ijackson/2018/bts-merges/more-graph.png > https://www.chiark.greenend.org.uk/~ijackson/2018/bts-merges/full-graph.png > https://www.chiark.greenend.org.uk/~ijackson/2018/bts-merges/bug.html > > The BTS-produced graph is really not very true. The BTS has a pretty simplistic view of versions, and views them as a directed acyclic graph. It builds the graph by assuming that the current version in the changelog is based on the immediately preceeding version in the changelog.[1] So you can order your changelog anyway you want, with the exception of the new version (must be first) and the version which it is based on (must be second).[2] Hopefully that clarifies things. 1: Actually, dak does this and supplies it to the BTS, but the idea is the same. 2: I don't remember right now what the logic is for versions which have never been in Debian which have a changelog entry, but I suspect that dak walks the version list until it finds a version which has been in Debian... maybe I should write up a blog post about this. -- Don Armstrong https://www.donarmstrong.com A Bill of Rights that means what the majority wants it to mean is worthless. -- U.S. Supreme Court Justice Antonin Scalia
