On 22 December 2010 21:25, Frederic Janssens <[email protected]> wrote: > On 2010-12-22, Ahmad Samir <[email protected]> wrote: >> On 22 December 2010 18:37, Frederic Janssens <[email protected]> wrote: >>> On 2010-12-22, Ahmad Samir <[email protected]> wrote: >>>> On 22 December 2010 01:32, Frederic Janssens <[email protected]> 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'. >
There's no way in bugzilla to do this at the moment (there's talk about this being implemented in bugzilla-4.0, which I haven't tried before). Traditionally the Whiteboard field was used for such issues (or separate reports were opened for each affected stable release). Having a multi-line RPM Package wouldn't be the way to go with this (IMHO). >>> (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. > Whatever. As long as that doesn't affect the workflow of the triage team or bugzilla's performance in general, I don't really care whichever way it get implemented :) [...] > -- > > Frederic > -- Ahmad Samir
