Maarten Vanraes a écrit :
Op woensdag 22 december 2010 20:38:06 schreef Ahmad Samir:
On 22 December 2010 21:30, Renaud MICHEL<[email protected]>
wrote:
On mercredi 22 décembre 2010 at 18:46, Ahmad Samir wrote :
Sorry for not beeing clear.
What I propose is not for the case 'a bug originates from more than
one package';
but for the case 'a bug manifests itself in than one package'.
If we agree that a bug can originate in more than one package, a
multiline (multi-rpm) field could be useful.
A bug that manifests in more than one package must originate from
'some package', that 'some package' is the only one that should be in
the 'RPM Package' field; i.e that's the package that's going to need
fixing.
I agree, but that doesn't mean the user is able to identify the
problematic package, even if he has good knowledge of the way packages
work.
Let's say for example that there is a problem with libxy, it is compiled
with a bad combination of optimizations that make some of its functions
behave randomly.
appA appB and appC use libxy, but appC only use simple functions that are
not affected by the optimization problem, so only appA and appB behave
badly.
Even if the user know about packages dependencies, as appC work fine he
may not come to the conclusion that libxy is causing the problem.
But he may still consider the problems with appA and appB to be related
because they started at the same time (the latest update that included
libxy).
So if he can fill a single bug report for both appA and appB, that is a
good hint to the developer that he should investigate in the
dependencies those apps have in common.
So if you accept only one package per bug report, it may be harder to
find the actual cause, as those two apps may be maintained by different
people, each investigating the problem for his own app.
Good point.
--
Renaud Michel
Sure, but there's strace and gdb crash backtraces, that's what devs
use to find where a crash/bug happens, whether it's in their
package/code or somewhere else.
To be more clear it's "one bug per report", that bug originates from a
package, that's what gets to be put in the 'RPM Package' field; it's
not unheard of that the 'RPM Package' field is changed through out the
life cycle of a bug report.
yes, but suppose there's a firefox issue and it appears to be a problem with a
system library, after it gets changed, people will never find this problem
again; since they look for firefox...
We could retain a reference to a package that manifests but doesn't
actually contain a bug by putting parentheses around its name.
- André
