[Mageia-dev] Proposal for bugzilla

Wed Dec 22 18:46:06 CET 2010

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:
+>>> On Wed, Dec 15, 2010 at 17:07, Michael Scherer <misc at zarb.org> wrote:
+>>>
+>>> In preparation of the future interaction (by xmlrpc) between the
+>>> mageia-app-db site and the mageia bugzilla,  I have been testing
+>>> http://bugs.mageia.org/ .
+>>> Xmlrpc works, but it will be necessary to configure additional fields.
+>>> The minimum would be to add an 'RPM Package' field (such as exists on
+>>> https://qa.mandriva.com/).
+>>>
+>>
+>> That's already agreed upon, whatever it's called, RPM Package or
+>> Component (I am in favour of the former).
+>
+> ok
+>
+>>> 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.
+
+> (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), whatever search method you use, it has to
+be versatile enough to cope with the field content variations.
+
+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).
+
+>
+>>
+>>> Perhaps also an 'Upstream' field which would, eventually, indicate
+>>> where that bug is filed upstream.
+>>>
+>>
+>> That's similar to the URL field in my proposal (see my previous post
+>> in this thread).
+>
+> Ok.
+>
+>>
+>>> Finally the "status whiteboard" could be enabled, and used to clearly
+>>> explain a workaround, for open bugs (instead of having to figure it
+>>> from the comments). (Eventually this field could also be used as the
+>>> 'Fixed RPM Packages' field when the bug is closed. So it would be the
+>>> 'Solution' field)
+>>>
+>>
+>> I don't think this will be adequately useful; if the issue is fixed,
+>> then all the user has to do is update his system. If it's not fixed
+>> and affects a stable release then it should get added to the Errata
+>> page for that release whether there's a workaround (or not); if it
+>
+> Still another place to look at. If it concerns the bug it would be
+> better to have it visible in the bug.
+>
+>> affects Cauldron, well, Cauldron users are supposed to be
+>> fireproof-ready, so they do read bug reports (or skim through them).
+>
+> 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).
+
+>
+>>
+>>> Apart from the "status whiteboard" which is a parameter to enable
+>>> (http://www.bugzilla.org/docs/tip/en/html/parameters.html);
+>>> the fields must be added as custom-fields
+>>> (http://www.bugzilla.org/docs/3.6/en/html/custom-fields.html)
+>>>
+>>>
+>>> --
+>>>
+>>> Frederic
+>>>
+>>
+>>
+>>
+>> --
+>> Ahmad Samir
+>>
+>
+>
+> --
+>
+> Frederic
+>
+
+
+
+-- 
+Ahmad Samir
+