Debian Bug report logs - #474742
Implement shared history of merged bugs at display level; cloning merged bugs to share history at log level

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Marcus Better <marcus@better.se>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: debbugs: cannot clone merged bug

Date: Mon, 07 Apr 2008 16:16:27 +0200

Package: debbugs
Severity: normal

I tried to clone a merged bug report in order to reassign the clone to
some other package, but got this:

 > # Automatically generated email from bts, devscripts version 2.10.20
 > clone 468191 -1
 Bug#468191: qt-x11-free-dbg: Maximize a window does not work correctly when in duealhead mode using xrandr
 Bug is marked as being merged with others. Use an existing clone.

I'm not really interested in reassigning any one of the original
merged bugs. They are for the original package and the
reporter/maintainer probably likes them to remain where they are.

Also the wording "Use an existing clone" doesn't make much sense since
the original bugs weren't cloned, but rather merged.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-rc8-lg (PREEMPT)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Message #14 received at 474742@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: Marcus Better <marcus@better.se>, 474742@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: Bug#474742: debbugs: cannot clone merged bug

Date: Mon, 7 Apr 2008 14:51:37 -0700

severity 474742 wishlist
tag 474742 wontfix
thanks

On Mon, 07 Apr 2008, Marcus Better wrote:
>  Bug is marked as being merged with others. Use an existing clone.
> 
> I'm not really interested in reassigning any one of the original
> merged bugs. They are for the original package and the
> reporter/maintainer probably likes them to remain where they are.

You still have to pick one of them; whether you unmerge one and
reassign or unmerge one, clone it, and remerge is up to you.

> Also the wording "Use an existing clone" doesn't make much sense
> since the original bugs weren't cloned, but rather merged.

If they're merged, they're the same bug, and therefore clones of
eachother.


Don Armstrong

-- 
Some pirates achieved immortality by great deeds of cruelty or
derring-do. Some achieved immortality by amassing great wealth. But
the captain had long ago decided that he would, on the whole, prefer
to achieve immortality by not dying.
 -- Terry Pratchet _The Color of Magic_

http://www.donarmstrong.com              http://rzlab.ucr.edu

Message #19 received at 474742@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Don Armstrong <don@debian.org>, 474742@bugs.debian.org

Cc: Marcus Better <marcus@better.se>

Subject: Re: Bug#474742: debbugs: cannot clone merged bug

Date: Tue, 8 Apr 2008 00:21:03 +0100

On Mon, Apr 07, 2008 at 02:51:37PM -0700, Don Armstrong wrote:
> On Mon, 07 Apr 2008, Marcus Better wrote:
> >  Bug is marked as being merged with others. Use an existing clone.
> > 
> > I'm not really interested in reassigning any one of the original
> > merged bugs. They are for the original package and the
> > reporter/maintainer probably likes them to remain where they are.
> 
> You still have to pick one of them; whether you unmerge one and
> reassign or unmerge one, clone it, and remerge is up to you.
> 
> > Also the wording "Use an existing clone" doesn't make much sense
> > since the original bugs weren't cloned, but rather merged.
> 
> If they're merged, they're the same bug, and therefore clones of
> eachother.

Clone copies the bug history, and thus it's useful to pick a particular
one of the merged bugs. I think having to unmerge/remerge is a right
pain and there isn't really a good non-implementation reason for it.

Merged bugs aren't clones of each other, because clones have divergent
state whereas merged bugs have synchronised state.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #24 received at 474742@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 474742@bugs.debian.org

Cc: Marcus Better <marcus@better.se>

Subject: Re: Bug#474742: debbugs: cannot clone merged bug

Date: Mon, 7 Apr 2008 16:20:18 -0700

tag 474742 -wontfix
retitle 474742 Implement shared history of merged bugs at display level; cloning merged bugs to share history at log level

On Tue, 08 Apr 2008, Colin Watson wrote:
> On Mon, Apr 07, 2008 at 02:51:37PM -0700, Don Armstrong wrote:
> > On Mon, 07 Apr 2008, Marcus Better wrote:
> > >  Bug is marked as being merged with others. Use an existing clone.
> > > 
> > > I'm not really interested in reassigning any one of the original
> > > merged bugs. They are for the original package and the
> > > reporter/maintainer probably likes them to remain where they are.
> > 
> > You still have to pick one of them; whether you unmerge one and
> > reassign or unmerge one, clone it, and remerge is up to you.
> > 
> > > Also the wording "Use an existing clone" doesn't make much sense
> > > since the original bugs weren't cloned, but rather merged.
> > 
> > If they're merged, they're the same bug, and therefore clones of
> > eachother.
> 
> Clone copies the bug history, and thus it's useful to pick a
> particular one of the merged bugs. I think having to unmerge/remerge
> is a right pain and there isn't really a good non-implementation
> reason for it.

The real issue is that cloning of merged bugs is currently
nonsensical, because there's no way (currently) to know which of the
merged bugs should be cloned unless you specify so explicitely.

This is partially an artifact of the way that merged bugs are
currently, and can't be fixed easily until that's changed.

Merged bugs should effectively end up being exactly identical with
shared history up until the point that they're unmerged (with the
shared history done at the display level) and cloning a merged bug
should cause a new bug to be created with the shared history done at
the log level.


Don Armstrong

-- 
Some pirates achieved immortality by great deeds of cruelty or
derring-do. Some achieved immortality by amassing great wealth. But
the captain had long ago decided that he would, on the whole, prefer
to achieve immortality by not dying.
 -- Terry Pratchet _The Color of Magic_

http://www.donarmstrong.com              http://rzlab.ucr.edu

Message #33 received at 474742@bugs.debian.org (full text, mbox, reply):

From: Marcus Better <marcus@better.se>

To: Don Armstrong <don@debian.org>

Cc: 474742@bugs.debian.org

Subject: Re: Bug#474742: debbugs: cannot clone merged bug

Date: Tue, 08 Apr 2008 10:28:50 +0200

Don Armstrong wrote:
> The real issue is that cloning of merged bugs is currently
> nonsensical, because there's no way (currently) to know which of the
> merged bugs should be cloned unless you specify so explicitely.

I thought that's exactly what I did in the bts clone command.

Cheers,

Marcus

Message #38 received at 474742@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Don Armstrong <don@debian.org>, 474742@bugs.debian.org

Cc: Marcus Better <marcus@better.se>

Subject: Re: Bug#474742: debbugs: cannot clone merged bug

Date: Tue, 8 Apr 2008 12:44:11 +0100

On Mon, Apr 07, 2008 at 04:20:18PM -0700, Don Armstrong wrote:
> On Tue, 08 Apr 2008, Colin Watson wrote:
> > Clone copies the bug history, and thus it's useful to pick a
> > particular one of the merged bugs. I think having to unmerge/remerge
> > is a right pain and there isn't really a good non-implementation
> > reason for it.
> 
> The real issue is that cloning of merged bugs is currently
> nonsensical, because there's no way (currently) to know which of the
> merged bugs should be cloned unless you specify so explicitely.

Why wouldn't you just want to copy the history of the bug you named in
the clone command (as Marcus observed, he did name a particular bug
explicitly), and just remove the state bit that indicates that it's
merged with another bug? If you keep all the history then it'll still
have a reference to its merge partners in the log.

> This is partially an artifact of the way that merged bugs are
> currently, and can't be fixed easily until that's changed.
> 
> Merged bugs should effectively end up being exactly identical with
> shared history up until the point that they're unmerged (with the
> shared history done at the display level) and cloning a merged bug
> should cause a new bug to be created with the shared history done at
> the log level.

Unless I've misunderstood you, I'm not convinced about this. The start
of such bugs would be extremely confusing to read.

The variant of this I'd prefer would be that mails sent to merged bugs
should be appended to the bug logs for all the merge partners (allowing
duplicates to be hidden by the display engine in the usual way), but
that the initial distinct history of the merged bugs before they were
merged should be preserved. Trying to glom them together would be awful.

I don't think we need anything more complicated than that.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #41 received at 474742@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 474742@bugs.debian.org

Subject: Re: Bug#474742: debbugs: cannot clone merged bug

Date: Tue, 8 Apr 2008 16:09:51 -0700

On Tue, 08 Apr 2008, Colin Watson wrote:
> Why wouldn't you just want to copy the history of the bug you named
> in the clone command (as Marcus observed, he did name a particular
> bug explicitly), and just remove the state bit that indicates that
> it's merged with another bug? If you keep all the history then it'll
> still have a reference to its merge partners in the log.

You can't just copy it, because you also need to indicate that the
cloned bug has been unmerged, otherwise the history is confusing to
read. [This latter bit blocks on finishing abstracting out control.]
This is one implementation possibility, but because it loses any
messages which were sent to the other cloned bugs it's not the optimal
one without the secondary change(s) below.

> Unless I've misunderstood you, I'm not convinced about this. The
> start of such bugs would be extremely confusing to read.
> 
> The variant of this I'd prefer would be that mails sent to merged
> bugs should be appended to the bug logs for all the merge partners
> (allowing duplicates to be hidden by the display engine in the usual
> way), but that the initial distinct history of the merged bugs
> before they were merged should be preserved. Trying to glom them
> together would be awful.

This means that bugs which are merged later will be less useful than
bugs which are merged earlier, which is suboptimal. I think this may
be a workable start until the proper solution is implemented, though.

Putting them together would require changing the way that we display
logs to respect threading but that's something that we need to do
anyway.


Don Armstrong

-- 
Q: What Can a Thoughtful Man Hope for Mankind on Earth, Given the
Experience of the Past Million Years?
A: Nothing.
 -- Bokonon _The Fourteenth Book of Bokonon_ (Vonnegut _Cats Cradle_)

http://www.donarmstrong.com              http://rzlab.ucr.edu

Send a report that this bug log contains spam.