Future task throwing it in..
Mark McLoughlin ( markmc@redhat.com )
Suggested this as an sensible policy for a tester to follow when reporting a bug
1) File the bug against the version you have tested with
2) If this version is not rawhide, there is generally no need to also file a bug against rawhide. Maintainers should always check whether the bug is fixed in rawhide. Commenting whether you believe the bug exists in rawhide is always useful.
3) If you think this is a critical bug and have checked that it exists other released versions, then you should clone the bug for those other versions.
4) Otherwise, just comment on the impact to other versions and let the maintainer decide whether cloning the bug is appropriate.
I do belive this is the best approach in that matter
As this is an arbitrary policy which lacks consensus, let me propose another arbitrary policy here:
Testers/Triagers: Keep bug reports at one and only one report per issue. If you notice a bug also affects another release and this is not already mentioned, post a comment to the bug report. (In some cases even that might not be necessary, e.g. if the affected EVR is exactly the same apart from the disttag, but posting an unnecessary comment should not hurt too much.) NEVER clone a bug unless there is an actually DIFFERENT issue involved (e.g. the same bug in another package, not another version of the same package).
Maintainers: Do not close a bug as RAWHIDE unless it either only affects Rawhide, is some trivial fix which does not affect runtime behavior of the package (e.g. a change to Summary/Description/URL, a License tag clarification, an unowned directory etc.) or cannot be fixed in releases (e.g. because a huge rewrite is needed to fix it). Instead, once you fixed it in Rawhide, set it to MODIFIED and immediately queue updates for all affected releases. Make sure they get queued for testing resp. stable at the same time for all affected releases.
The title of this ticket seems to mismatch with the content. Should we rename this ticket to "Write bug filing procedures and practices?"
Yup.
We have on the Wiki:
Neither of these entirely covers the issue of 'how to handle bugs which affect multiple releases', but there's no single good answer to that, and I'm not sure attempting to prescribe one or other of the possible and more-or-less-equally-flawed approaches would be a) helpful or b) successful. It's probably best to leave it up to maintainers how they wish to handle it for their own components.
Login to comment on this ticket.