On Wed, Jan 21, 2009 at 07:39:59PM +0100, Kevin Kofler wrote:
> Bruno Wolff III wrote:
> > You can also clone the bug and have one for each version.
>
> Well, maybe some maintainers like that, but my standpoint is: please don't!
>
> We generally know what releases are affected by a given bug, we'll just push
> the fix everywhere once we have one. Having multiple bugs for the same
> issue is annoying. So for stuff I (co)maintain, don't be surprised if I
> close your cloned bug as a duplicate and complain about the unnecessary
> cloning.
>
> This is also something I really dislike about the security bug procedure.
> One bug per release may make sense for RHEL, but for Fedora it's just an
> annoyance.
In my experience good bugs (productive bugs) have a couple things in common.
- good description
- focus (one bug per bug report)
- ability to reproduce and test (test case).
all of which imply that the bug not be cloned.
A bug fix process ends with delivery to the customer and depends on
productive bugs as the first step. The package/ product maintainer
works most commonly on the leading edge of the source tree to
resolve the issue.
The next step in the process involves pulling/ pushing the fix into one
or more release trees for testing and delivery to the end user. This is
the step where things fork to multiple versions and may or may not require
back porting. i.e. At this point each back port or distro might need
its own bug for tracking, management and source control system interface.
Most bug systems are developer and primary source tree centric missing the final
testing, distribution, QA and delivery steps (for good reason).
In an ideal world a bug system should be part of a bug fix process that can
take a list of "observed in" or "verified in" distros and generate action
tickets/ bugs when a bug is resolved in the primary source tree. If the "observed in"
was an RPM number, RPM rules like updates, replaces and obsoletes could be used
to automate additional state tracking. It is not sufficient to report F9 or F10.
A specific RPM tracks back to a source package (SRPM) which is the foundation to
apply patches and backport fixes to.
Automation can include end user notification to update and retest when any
"reported on" package was updated. i.e. something like:
Your bug report #123456 (URI) against
moodle-1.9.3-4.fc10.noarch.rpm
may be addressed by an update
moodle-1.9.3-5.fc10.noarch.rpm
released on `date -u` to rawhide or updates please retest and update
the bug report based on your results.
Hidden behind Fedora Linux is a web of links back to a long list of project
source trees each with their own bug systems that any distro bug system
needs to play with. Since distro bug systems often live outside most
project bug systems cloning bugs in a distro bug system does not help
until after the bug has been addressed in the tip of the source tree.
Also since the world is not all Red hat and Fedora, package hooks in bugzilla
should be flexible and not restricted to RPMs (see also source control system
hooks too).
One complement to clone is dupe. If you have a clean bug report with precise data
and a precise test case that is 'better' than any existing bug report it can be
productive to open a new bug with a small comment that it might be a duplicate
of some other bug. The owner of the issue can decide which is a dup of which.
In most cases a simple ADD of information is best.
Summary: 'cloning' adds work. If done too soon it adds confusion.
Let the bug owner and distro keeper clone and dupe their bugs to facilitate their work flow.
--
Regards,
T o m M i t c h e l l
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
