Bugs in gnucash bugzilla which aren't gnucash bugs

[Christian Stimming]

Am Dienstag, 8. September 2009 16:36 schrieb Phil Longstaff:
> At another company I worked at, if a bug was found while using our product,
> it was entered in our database.  Made sense, since it was a flaw in what we
> presented to the world.  If, after analysis, we found that it was really a
> bug in an external dependency, we cloned the original bug to the
> dependency's database, and put our bug in a "wait for dependency" state.
>
> There are a number of bugs in the gnucash bugzilla db which are not really
> gnucash bugs.  Examples are Finance::Quote bugs.  I think it is helpful to
> keep those bugs, so that we have a full picture of the ways in which
> gnucash doesn't work, even if gnucash isn't the software which needs to be
> fixed.  However, there is no "wait for dependency" state available.  My
> suggestion is that we mark those bugs as ASSIGNED and have a special
> "person" that the bug is assigned to.  I would suggest an separate assignee
> per dependency (F::Q, GTK+, gtk_print, gtkhtml, webkit, ...).

F::Q is the single special case that we've got to deal with. Any maybe webkit. 
The others by coincidence are managed through the very same bugzilla, so we 
can easily either change the product to GTK+, gtk_print, or whatever, or add 
a dependency "This bug depends on ..." where the other bug is the one filed 
against this product.

As for F::Q and the assignee: I think the assignee should still be a normal 
person, namely a volunteer who will actually be reponsible for this area of 
gnucash and hopefully also to some extent for F::Q itself. Or, in other 
words: I wouldn't use the assignee field for marking bugs as different from 
other bugs. Switching the status to ASSIGNED is probably fine, and of course 
the component should be switch to F::Q. I don't think it is possible to do 
anything more in current bugzilla, sorry.

Christian