[Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

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