From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20101222/001852.html | 109 ++++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101222/001852.html (limited to 'zarb-ml/mageia-dev/20101222/001852.html') diff --git a/zarb-ml/mageia-dev/20101222/001852.html b/zarb-ml/mageia-dev/20101222/001852.html new file mode 100644 index 000000000..3c8d0eb37 --- /dev/null +++ b/zarb-ml/mageia-dev/20101222/001852.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Proposal for bugzilla + + + + + + + + + +

[Mageia-dev] Proposal for bugzilla

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Dec 22 20:38:06 CET 2010 +

+
+ +
On 22 December 2010 21:30, Renaud MICHEL <r.h.michel+mageia at gmail.com> 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'.
+>>
+>> 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.
+>
+> --
+> 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.
+
+-- 
+Ahmad Samir
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1