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/001860.html | 121 ++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101222/001860.html (limited to 'zarb-ml/mageia-dev/20101222/001860.html') diff --git a/zarb-ml/mageia-dev/20101222/001860.html b/zarb-ml/mageia-dev/20101222/001860.html new file mode 100644 index 000000000..ee1d05d2a --- /dev/null +++ b/zarb-ml/mageia-dev/20101222/001860.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Proposal for bugzilla + + + + + + + + + +

[Mageia-dev] Proposal for bugzilla

+ andre999 + andr55 at laposte.net +
+ Wed Dec 22 22:58:44 CET 2010 +

+
+ +
Maarten Vanraes a écrit :
+>
+> Op woensdag 22 december 2010 20:38:06 schreef Ahmad Samir:
+>> 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'.
+
+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é
+
+ + + + +
+

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