On Tue, 09 Jan 2018, Ian Jackson wrote:
> Don Armstrong writes ("Re: Bug#886645: want guidance for changelogs when
> history is merge-ish"):
> > On Tue, 09 Jan 2018, Ian Jackson wrote:
> > > * Each node inherits the merger of the bug map of its parents
> &g
Don Armstrong writes ("Re: Bug#886645: want guidance for changelogs when
history is merge-ish"):
> On Tue, 09 Jan 2018, Ian Jackson wrote:
> > * Each node inherits the merger of the bug map of its parents
> >When merging, for each key we take the largest value fo
On Tue, 09 Jan 2018, Ian Jackson wrote:
> | What about making the BTS support DAGs which are not trees? I think
> | something like this would be useful, but I don't personally have a
> | good idea on how this could be specified using the changelog or how
> | bug fixed/found/absent should be propaga
Don Armstrong writes ("Re: Bug#886645: want guidance for changelogs when
history is merge-ish"):
> I worked back through this in
> https://www.donarmstrong.com/posts/debbugs_merge_versions/ and I think
> that has a better explanation of what is actually happening using d
On Mon, 08 Jan 2018, Don Armstrong wrote:
> On Mon, 08 Jan 2018, Ian Jackson wrote:
> > I don't think this explanation can be sufficient to see what I saw.
> > In my case, the upload of a new version (4.2) caused the reordering
> > of a few previous versions.
>
> Hrm; yeah, that doesn't match what
On Mon, 08 Jan 2018, Ian Jackson wrote:
> "The" "immediately preceeding" version ? You mean its single immediate
> ancestor I think. But of course in the presence of merges there maybe
> more than one immediate ancestor.
Right. It's just that the BTS doesn't know about merges. [This is really
beca
Don Armstrong writes ("Re: Bug#886645: want guidance for changelogs when
history is merge-ish"):
> 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 change
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
Package: bugs.debian.org
My package has a mergeing history, and bugs.debian.org has become
confused.
The real history is like this:
4.2
sid
+
9 matches
Mail list logo
