[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reassigning Bugs

On Tuesday 26 September 2006 15:39, Benjamin Mesing wrote:
> On Tue, 2006-09-26 at 15:20 +0300, George Danchev wrote:
> > On Monday 25 September 2006 16:19, Benjamin Mesing wrote:
> > > > clone 12345 -1
> > > > reassign -1 apt-file
> > > > retitle -1 apt-file: known to break packagesearch ...
> > > > thanks
> > >
> > > However, the bugs live seperated from each other after cloning. So this
> > > seems to be more convenient way of doing option 1 (without the blocking
> > > thing), right?
> >
> > Right. This in fact is one and the same bug, but cloned, showing in
> > packagesearch and apt-file bug records. When it gets closed it does that
> > for both packages.
> If I understand you correctly, this creates only an alias for the
> existing bug report. Please confirm that you are sure about this, it
> seems to contradict with what is written in the BTS documentation:
>         clone bugnumber NewID [ new IDs ... ]
>         The clone control command allows you to duplicate a bug report.
>         It is useful in the case where a single report actually
>         indicates that multiple distinct bugs have occurred. "New IDs"
>         are negative numbers, separated by spaces, which may be used in
>         subsequent control commands to refer to the newly duplicated
>         bugs. A new report is generated for each new ID.
> The line that a new report is created for each new ID seems to indicate
> that an independent report (and not just an alias is created).
> Additionally having only an alias, would contradict the goal of
> splitting multiple disitinct bugs from a single report.

	I think you are correct and my 'alias' interpretaton was flawed, ... we need 
distinct $bugnumber for these cloned bugs, after all ;-) 
	So, if I were you I would go for: clone & reassign that bug to apt-file, and 
close the bug against packagesearch with an reasonable 'explanation' so that 
any prospective bug-filers have a chance to know that such a packagesearch 
issue is already known.

pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 

Reply to: