[QA] To clone or not to clone ( a bug report ) that's the question...

[Jesse Keating]

On Thu, 2009-01-22 at 00:39 +0100, Kevin Kofler wrote:
> Jesse Keating wrote:
> >   1) the same "bug" may be caused by different things in different
> > releases.  Not every package has the same code for the entire release
> > family.
> 
> That's pretty rare. Even where the version differs, the bug can still be the
> same. Even for Amarok 1 and 2, which are very different, there are bugs in
> common with almost the same code involved (like the recently-fixed security
> issue).

Might be rare in your world, but isn't rare in mine.

> >   2) different sets of users care about bugs in different release trees.
> > Closing a bug as fixed->rawhide doesn't help the user who is hitting
> > this issue on say F-9.
> 
> Solution: make it a policy that bugs should never be closed Rawhide unless
> they only affected Rawhide. It should also be required to push bugfixes out
> to at least updates-testing as soon as the bug gets fixed in Rawhide,
> unless there is a really good reason not to (e.g. the fix needs a rewrite
> of the whole application).

Then that just means our rawhide bug lingers open even when it may be
fixed, which throws off trackers and blockers and queries.  Not a
solution.

> 
> >   3) bodhi auto-closing.  Not every update gets pushed at the same time,
> 
> Then that's the issue to solve.

Right, and how do you propose we "solve" this (not that I agree that
this is a problem)?

> 
> > and closing a single bug when an F-10 update goes out doesn't help the
> > F-9 users know that the update for their release has gone out, or been
> > delayed, or just not provided.
> 
> But having the bug cloned does not solve this, requiring bugfixes to be
> pushed to all supported releases at the same time (unless there's a strong
> reason not to) does.

At the same time doesn't work.  What if your attempted fix on F-9 fails,
but the fix on F-10 succeeds?  Should the F-10 build sit in
updates-testing until the say that F-9 works?  F-10 users just suffer
for the sake of having the push go at the same time?  Ridiculous.

> 
> >   4) The maintainer is the right person to decide if the bugs should be
> > collapsed into one, rather than the triager trying to make a judgement
> > call.  It's easier to close->dup than to clone in the first place, if
> > all the above doesn't apply.
> 
> I really don't want to have to close clones as duplicates all the time, and
> triagers might even end up creating new clones if they notice there's only
> one.

You can always opt out of having triagers touch KDE bugs.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090121/b77ca617/attachment.bin