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

[Mageia-dev] Proposal for bugzilla

+ Frederic Janssens + fjanss at gmail.com +
+ Wed Dec 22 20:25:20 CET 2010 +

+
+ +
On 2010-12-22, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+> On 22 December 2010 18:37, Frederic Janssens <fjanss at gmail.com> wrote:
+>> On 2010-12-22, Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+>>> On 22 December 2010 01:32, Frederic Janssens <fjanss at gmail.com> wrote:
+
+>>>> First I think it would be usefull to have a multiline (Large Text Box)
+>>>> 'RPM Packages' field, instead of a single line (Free Text) field as
+>>>> used by mandriva.
+>>>> A single bug can concern more than one rpm. One thing mageia-app-db
+>>>> will do is search all bugs affecting an rpm. For that search to be
+>>>> meaningfull all affected rpms should be mentioned.
+>>>
+>>> 'One bug per report' is what we should do (did); if a bug originates
+>>> from more than one package, a separate report for each of them should
+>>> be opened with the Block/Dependency set correctly.
+>>
+>> 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.
+
+Sorry again, what I mean, and should have written, is :
+'a bug manifests itself in one package, but in more than one -version-release'.
+
+>> (In fact I think I want to solve the same problem you want to solve with
+>> "with a whiteboard field to state if the bug affects more than one release
+>> (at
+>> least for now)"
+>> but in a more specific manner).
+
+
+
+>>
+>>>
+>>>> For the same reason, the way the rpms are mentioned should be
+>>>> 'standardised',
+>>>> as the search done by bugzilla can only be litteral.
+>>>>
+>>>
+>>> Usually one doesn't only search in the RPM Package field; experience
+>>> tell us that the affected package name will be mentioned many times in
+>>> both the summary and the description.
+>>>
+>>> And if you want to search in the RPM Package field, bugzilla has many
+>>> options to do so, look at the bottom of:
+>>> https://qa.mandriva.com/query.cgi?format=advanced
+>>
+>> Yes; but I am trying to solve the connection with mageia-app-db.
+>> With the xmlrpc interface it seems the search possibilities are more
+>> limited :
+>> (from
+>> http://www.bugzilla.org/docs/3.6/en/html/api/Bugzilla/WebService/Bug.html)
+>> :
+>>
+>> "
+>> search
+>>
+>>    UNSTABLE
+>>
+>>    Description
+>>
+>>        Allows you to search for bugs based on particular criteria.
+>>    Params
+>>
+>>        Unless otherwise specified in the description of a parameter,
+>> bugs are returned if they match exactly the criteria you specify in
+>> these parameters. That is, we don't match against substrings--if a bug
+>> is in the "Widgets" product and you ask for bugs in the "Widg"
+>> product, you won't get anything.
+>>
+>>        Criteria are joined in a logical AND. That is, you will be
+>> returned bugs that match all of the criteria, not bugs that match any
+>> of the criteria.
+>>
+>>        Each parameter can be either the type it says, or an array of
+>> the types it says. If you pass an array, it means "Give me bugs with
+>> any of these values." For example, if you wanted bugs that were in
+>> either the "Foo" or "Bar" products, you'd pass:
+>>
+>>         product => ['Foo', 'Bar']
+>> "
+>>
+>
+> I don't know about xmlrpc, but there's no one certain way to fill the
+> 'RPM Package' field; ideally it should be packagename-version-release
+> (e.g. kwrite-4.5.85-1mdv),
+
+That's what I proposed in another post.
+If that were the standard, there would be no problem for mageia-app-db.
+
+> whatever search method you use, it has to
+> be versatile enough to cope with the field content variations.
+
+To be clear : as indicated above,
+the limitation is in what bugzilla offers through it's xmlrpc interface.
+We should have to modify the bugzilla code if we wanted access to it's
+'advanced search'
+through it's xmlrpc interface.
+
+
+>
+> FWIW, the best way to search a bugzilla is using the Advanced search
+> interface; just searching for the package name isn't enough. Usually
+> it's not a problem for active triage team members to spot duplicates
+> (from daily contacts with bug reports) and mark them as such.
+>
+>>>
+>>>> Something that does not exist in mandriva, but I think would be usefull,
+>>>> is a
+>>>> 'Fixed RPM Packages' that would be filled when the bug is fixed. FIXED
+>>>> is great, but where (or since which rpm)?
+>>>>
+>>>
+>>> IMHO, that's trivia; either the user is savvy enough / has the time to
+>>> trudge through the bug report to find out which package release fixes
+>>> an issue (which indicates he's the curious type, he'll at least skim
+>>> through the bug report anyway), or he's just going to update his
+>>> system and get the fix (the latter happens more often).
+>>
+>> Here the 'user' is mageia-app-db.
+>>
+>
+> Then this is a premature question; you should wait first to see how
+> the updates in stable releases are going to be handled (will
+> everything have to go through the sec team? or sec team will only care
+> about the essential packages only?... etc because in that case a
+> security announcement is dispatched, you may be able to grab the
+> "fixed" version from there).
+
+Ok
+
+>> How is the case represented where the bug is in release,
+>> and the fix is in cauldron ?
+>>
+>
+> Then it's not fixed in the afro-mentioned stable release, and should
+> be in the Errata (if it's an important package, of course).
+>
+
+Ok
+
+-- 
+
+Frederic
+
+ + + + + + +
+

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