Re: [Mageia-dev] Proposal for bugzilla

[Maarten Vanraes]

Op zaterdag 25 december 2010 12:02:18 schreef andre999:
 Maarten Vanraes a écrit :
  Op zaterdag 25 december 2010 10:18:17 schreef andre999:
  Maarten Vanraes a écrit :
  Op donderdag 23 december 2010 22:23:56 schreef Ahmad Samir:
  On 23 December 2010 22:01, Samuel Verscheldesto...@laposte.net   
wrote:
  I remember some years ago you could choose the exact version of the
  package for which you reported a bug, from a list. I agree that
  improving the UI side helpers could be useful.
  
  Regards
  
  Samuel Verschelde
  
  As was said by dmorgan, listing each SRPM slowed down bugzilla a lot;
  the distro has a lot of SRPMS...
  
  an ajax search is better; it doesn't add much and only gets searched if
  you enter at least 2 chars, or something like that.
  
  if such an ajax is wanted, i can write that if i can use app-mageia-db
  or similar as a list.
  
  OK, I did a little search on Ajax, and I think that I understand now.
  It seems that you're proposing autocompletion on the text typed in the
  field - and only matches will be downloaded.
  But if it starts with 2 characters, there could be still 1000's of names
  downloaded.
  I would suggest that we would need at least 5 characters to restrict the
  names downloaded to a reasonable number.
  
  Also, there is another factor.  If we are looking for srpm names, but
  the user enters binary rpm names, there will not necessarily be a match,
  particularly if the srpm results in more than one binary rpm.
  So in some cases this will not work.
  
  But I have another idea.
  Maybe we could have separate (binary) rpm and srpm fields.
  There is a button on the page, which will invoke the command to give the
  srpms associated with the binary rpms.
  Would this be workable ?
  Something that would execute
  
 $ rpm -q --qf '{sourcerpm}' {pkg-name}
  
  and would automatically enter the result in the srpm field, or at least
  display it so it could be typed in.
  
  Of course, this would have to be done by the user experiencing the
  problems, to ensure having the correct version.
  We would also have to deal with the cases where more than one rpm has
  the bug.
  
  If we can automate this, we can dispense with the potential problems
  associated with a list of srpms.  And it would be (at least somewhat)
  more efficient both server and client side, as well.
  
  Just an idea
  
  André
  
  this is no more than sort of TAB completion on the urpmi commands.
 
 That part I understand.
 Only these values will be downloaded, so some online traffic.
 
  averagely 2 characters have ~600 possibilities; meaning that 2 chars give
  average 25 srpm results. in practice this can be 150 results or something
 
 Your numbers are right.  Obviously I had one too many zeros.
 
  consider also the fact that these are src.rpm , so huge lib and the
  fact that we won't be starting with everything...
 
 I was thinking of lib*, which is why I said more than 3 characters.
 
  imho instead of destroying an idea you don't know much about; why don't i
  implement it and then you can evaluate if it's bad or not.
 
 Actually, I was trying brainstorming.  We all know that such ideas don't
 necessarily lead anywhere.
 It is certain that your idea is a lot better than it first appeared.

yeah, sorry, i (and misc) just am trying to suggest an idea that gets broken 
off by people who don't even seem to get it; coupled with less sleep and my 
cranky, i could've worded it better

 However, invoking the rpm command has certain advantages.
 Most importantly, if done on the system of the user finding the bug, it
 reports exactly the correct version of the srpm.
 
 For example, on my system, if I type in the console exactly :
 
 rpm -q --qf '%{sourcerpm}' binutils
 
 _without_ the version, it returns :
 
 binutils-2.19.51.0.2-1mnb2.src.rpm
 
 _with_ the version, which is exactly what we want.
 
 So I have a suggestion.
 With your Ajax skills, I imagine that you would be capable of setting a
 button which automatically invokes that command on a binary rpm field,
 to fill a srpm field ?
 Could you try that as well ?
 If it works, then I think we would have a better solution.

i'm not certain that is required, iirc, the command to find this stuff is out 
there; and the info can be found on mageia-app-db i think.

however, if it isn't a src.rpm but a perfect match for a binary rpm, i guess 
we could return the src.rpm instead.

 I could try it, but my html/javascript skills are quite limited.
 Just a suggestion.
 
 Regards
 
 André

Re: [Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

On 25 December 2010 02:04, andre999 and...@laposte.net wrote:

[...]

 In my mind, it is triage and QA who would benefit the most from such a list.

Not really, QA and Triage already use Sophie
http://mageia.org/wiki/doku.php?id=irc#sophie

 It seems if we were to have such a list, that it might be better to make it
 a separate (web) application, which could be referred to in a separtate
 tab/window, so it is charged only once for reviewing a number of bugs.
 But if triage/QA is not interested, it is better to avoid this big list.

 Another thought : maybe we should have separate rpm and srpm fields.
 Because end-users will relate more to ordinary rpm's, several of which could
 be generated by the same srpm.
 Do you think that would be useful ?

 my 2 cents :)

 André



One field is enough, a package maintainer knows what rpms come from
which of his SRPMs. The RPM Package field main goal is indicating
where the bug exists as that's where it'll, hopefully, get fixed.

-- 
Ahmad Samir

Re: [Mageia-dev] Proposal for bugzilla

[Samuel Verschelde]

Le vendredi 24 décembre 2010 01:20:41, Dexter Morgan a écrit :
 On Thu, Dec 23, 2010 at 11:22 PM, Ahmad Samir ahmadsamir3...@gmail.com 
wrote:
  On 24 December 2010 00:13, Maarten Vanraes maarten.vanr...@gmail.com 
wrote:
  Op donderdag 23 december 2010 22:23:56 schreef Ahmad Samir:
  On 23 December 2010 22:01, Samuel Verschelde sto...@laposte.net wrote:
   I remember some years ago you could choose the exact version of the
   package for which you reported a bug, from a list. I agree that
   improving the UI side helpers could be useful.
   
   Regards
   
   Samuel Verschelde
  
  As was said by dmorgan, listing each SRPM slowed down bugzilla a lot;
  the distro has a lot of SRPMS...
  
  an ajax search is better; it doesn't add much and only gets searched if
  you enter at least 2 chars, or something like that.
  
  if such an ajax is wanted, i can write that if i can use app-mageia-db
  or similar as a list.
  
  If the user doesn't know how to find the package info (rpm -q
  packagname), no auto-complete is going to help much, he'll just pick
  one of them randomly (top of the list, or bottom of the list). It's
  not much to ask for rpm -q output...
  
  --
  Ahmad Samir
 
 and this method is deprecated ( i mean the big list ) because this
 slow down too much the server.

No one talked about having back the big list. However an ajax auto-complete on 
an indexed field usually doesn't ask too much from the server.

Regards

Samuel Verschelde

Re: [Mageia-dev] Proposal for bugzilla

[Maarten Vanraes]

Op vrijdag 24 december 2010 11:37:21 schreef Samuel Verschelde:
 Le vendredi 24 décembre 2010 01:20:41, Dexter Morgan a écrit :
  On Thu, Dec 23, 2010 at 11:22 PM, Ahmad Samir ahmadsamir3...@gmail.com
 
 wrote:
   On 24 December 2010 00:13, Maarten Vanraes maarten.vanr...@gmail.com
 
 wrote:
   Op donderdag 23 december 2010 22:23:56 schreef Ahmad Samir:
   On 23 December 2010 22:01, Samuel Verschelde sto...@laposte.net 
wrote:
I remember some years ago you could choose the exact version of the
package for which you reported a bug, from a list. I agree that
improving the UI side helpers could be useful.

Regards

Samuel Verschelde
   
   As was said by dmorgan, listing each SRPM slowed down bugzilla a lot;
   the distro has a lot of SRPMS...
   
   an ajax search is better; it doesn't add much and only gets searched
   if you enter at least 2 chars, or something like that.
   
   if such an ajax is wanted, i can write that if i can use app-mageia-db
   or similar as a list.
   
   If the user doesn't know how to find the package info (rpm -q
   packagname), no auto-complete is going to help much, he'll just pick
   one of them randomly (top of the list, or bottom of the list). It's
   not much to ask for rpm -q output...
   
   --
   Ahmad Samir
  
  and this method is deprecated ( i mean the big list ) because this
  slow down too much the server.
 
 No one talked about having back the big list. However an ajax auto-complete
 on an indexed field usually doesn't ask too much from the server.
 
 Regards
 
 Samuel Verschelde

exactly; that's what i mean.

it needn't even be enforced, just color background green if recognized or 
something and giving suggestions when typing

Re: [Mageia-dev] Proposal for bugzilla

[Michael scherer]

On Fri, Dec 24, 2010 at 01:20:41AM +0100, Dexter Morgan wrote:
 On Thu, Dec 23, 2010 at 11:22 PM, Ahmad Samir ahmadsamir3...@gmail.com 
 wrote:
  On 24 December 2010 00:13, Maarten Vanraes maarten.vanr...@gmail.com 
  wrote:
  Op donderdag 23 december 2010 22:23:56 schreef Ahmad Samir:
  On 23 December 2010 22:01, Samuel Verschelde sto...@laposte.net wrote:
   I remember some years ago you could choose the exact version of the
   package for which you reported a bug, from a list. I agree that
   improving the UI side helpers could be useful.
  
   Regards
  
   Samuel Verschelde
 
  As was said by dmorgan, listing each SRPM slowed down bugzilla a lot;
  the distro has a lot of SRPMS...
 
  an ajax search is better; it doesn't add much and only gets searched if you
  enter at least 2 chars, or something like that.
 
  if such an ajax is wanted, i can write that if i can use app-mageia-db or
  similar as a list.
 
 
  If the user doesn't know how to find the package info (rpm -q
  packagname), no auto-complete is going to help much, he'll just pick
  one of them randomly (top of the list, or bottom of the list). It's
  not much to ask for rpm -q output...
 
  --
  Ahmad Samir
 
 
 and this method is deprecated ( i mean the big list ) because this
 slow down too much the server.

The server, or the the browser ?
( because server side, that's just a SQL query likely in cache, while 
browser side, you have to render a enormous 15 000 items list,
with allocation of objects, etc, etc ).
-- 
Michael Scherer 

Re: [Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

On 24 December 2010 13:02, Michael scherer m...@zarb.org wrote:
 On Fri, Dec 24, 2010 at 01:20:41AM +0100, Dexter Morgan wrote:
 On Thu, Dec 23, 2010 at 11:22 PM, Ahmad Samir ahmadsamir3...@gmail.com 
 wrote:
  On 24 December 2010 00:13, Maarten Vanraes maarten.vanr...@gmail.com 
  wrote:
  Op donderdag 23 december 2010 22:23:56 schreef Ahmad Samir:
  On 23 December 2010 22:01, Samuel Verschelde sto...@laposte.net wrote:
   I remember some years ago you could choose the exact version of the
   package for which you reported a bug, from a list. I agree that
   improving the UI side helpers could be useful.
  
   Regards
  
   Samuel Verschelde
 
  As was said by dmorgan, listing each SRPM slowed down bugzilla a lot;
  the distro has a lot of SRPMS...
 
  an ajax search is better; it doesn't add much and only gets searched if 
  you
  enter at least 2 chars, or something like that.
 
  if such an ajax is wanted, i can write that if i can use app-mageia-db or
  similar as a list.
 
 
  If the user doesn't know how to find the package info (rpm -q
  packagname), no auto-complete is going to help much, he'll just pick
  one of them randomly (top of the list, or bottom of the list). It's
  not much to ask for rpm -q output...
 
  --
  Ahmad Samir
 

 and this method is deprecated ( i mean the big list ) because this
 slow down too much the server.

 The server, or the the browser ?
 ( because server side, that's just a SQL query likely in cache, while
 browser side, you have to render a enormous 15 000 items list,
 with allocation of objects, etc, etc ).
 --
 Michael Scherer


Exactly. So if this get implemented I'd like it to be optional, i.e. I
can still turn it off in my bugzilla preferences.

-- 
Ahmad Samir

Re: [Mageia-dev] Proposal for bugzilla

[andre999]

Ahmad Samir a écrit :


On 24 December 2010 13:02, Michael schererm...@zarb.org  wrote:

On Fri, Dec 24, 2010 at 01:20:41AM +0100, Dexter Morgan wrote:

On Thu, Dec 23, 2010 at 11:22 PM, Ahmad Samirahmadsamir3...@gmail.com  wrote:

On 24 December 2010 00:13, Maarten Vanraesmaarten.vanr...@gmail.com  wrote:

Op donderdag 23 december 2010 22:23:56 schreef Ahmad Samir:

On 23 December 2010 22:01, Samuel Verscheldesto...@laposte.net  wrote:

I remember some years ago you could choose the exact version of the
package for which you reported a bug, from a list. I agree that
improving the UI side helpers could be useful.

Regards

Samuel Verschelde


As was said by dmorgan, listing each SRPM slowed down bugzilla a lot;
the distro has a lot of SRPMS...


an ajax search is better; it doesn't add much and only gets searched if you
enter at least 2 chars, or something like that.

if such an ajax is wanted, i can write that if i can use app-mageia-db or
similar as a list.



If the user doesn't know how to find the package info (rpm -q
packagname), no auto-complete is going to help much, he'll just pick
one of them randomly (top of the list, or bottom of the list). It's
not much to ask for rpm -q output...

--
Ahmad Samir



and this method is deprecated ( i mean the big list ) because this
slow down too much the server.


The server, or the the browser ?
( because server side, that's just a SQL query likely in cache, while
browser side, you have to render a enormous 15 000 items list,
with allocation of objects, etc, etc ).
--
Michael Scherer



Exactly. So if this get implemented I'd like it to be optional, i.e. I
can still turn it off in my bugzilla preferences.


Not only that, it should be off by default.
End users tend to use the default configurations, and the last thing we 
need is a bugzilla so slow that end users will be dicouraged from 
reporting bugs.

In my mind, it is triage and QA who would benefit the most from such a list.
It seems if we were to have such a list, that it might be better to make 
it a separate (web) application, which could be referred to in a 
separtate tab/window, so it is charged only once for reviewing a number 
of bugs.

But if triage/QA is not interested, it is better to avoid this big list.

Another thought : maybe we should have separate rpm and srpm fields.
Because end-users will relate more to ordinary rpm's, several of which 
could be generated by the same srpm.

Do you think that would be useful ?

my 2 cents :)

André

Re: [Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

On 23 December 2010 00:34, Samuel Verschelde sto...@laposte.net wrote:
 Le mercredi 22 décembre 2010 21:25:39, Michael scherer a écrit :

 On Wed, Dec 22, 2010 at 01:55:02PM +0100, Frederic Janssens wrote:
  On 2010-12-22, Michael Scherer m...@zarb.org wrote:
   Le mercredi 22 décembre 2010 à 00:32 +0100, Frederic Janssens a écrit :
   On Wed, Dec 15, 2010 at 17:07, Michael Scherer m...@zarb.org wrote:
   
Le mardi 14 décembre 2010 à 17:05 +0100, Dexter Morgan a écrit :
 I would like to have your input to let us able to provide a bugzilla
 really soon
   
So if I am not wrong, in bugzilla, we have :
- products
- component, contained in products
- and various field, per bug,
   
and the way we organize everything will impact the layout.
   
  
   Yes.
  
   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/).
  
   What about component not related to rpm ?
 
  The 'RPM Package' field would be left blank.
  (usually many fields are left blank)

 That's quite useless clutter in this case :/

  
   And do you mean srpm or rpm ?
 
  On https://qa.mandriva.com/ anything goes.
  To permit consistent searches I think we should standardise.
  The aim would to be to as specific as needed but not more;
  as far as I know that would be :
 
  name-version-release
 
  unless the bug is architecture specific, where we would have :
 
  name-version-release.architecture

 There is already a architecture field, afaik, as well as a version field,
 no ?

 ( I didn't check as I refuse to enter my password over a insecured http 
 session ).

 And I think that giving rpm ( and not srpm ) will make search a little bit 
 complex
 in some corner cases ( can will also cause problem for the next point ).


 So you think the (S)RPM field should only contain SRPM filenames ?

 If yes, I agree with that, because as Frederic stated above, in current 
 Mandriva bugzilla, there's no enforced rule for that. You can put anything in 
 the field, and you often end up with rpm filenames, or simple package names 
 (e.g. virtualbox).

 However asking bug reporters to know the SRPM is too much, so this rule can 
 only be enforced on Packagers and Triage Team side I think. This is already 
 how it works on qa.mandriva.com : if you know the SRPM, you put it, if not 
 someone will triage and do it for you.

 Ahmad, would there be a problem in enforcing such a policy (i.e. SRPM field 
 should be empty or contain a valid SRPM name ? Where valid means looks like 
 the name of a SRPM) ?

 Regards

 Samuel Verschelde


Actually virtualbox is a valid enough SRPM name, because if you put
virtualbox in the RPM Package field bugzilla will auto-assign to the
package maintainer. And putting the arch. of the package in that field
isn't so useful, there's a separate Architecture field in each report.

How do you wanna enforce this? by rejecting anything the user puts in
that field if it's not correct? well, I expect that we'll get less
reports this way, good from the triage team workload POV :), bad from
the POV that some important reports won't be filed because the user
doesn't understand what you want him to do.

I have no problem with having a report with a wrong content in the RPM
Package field, that can be fixed. So no, I am not OK with enforcing
anything here, just offering this as a guide line that it should be
'kwrite-4.5.5-1mga' rather than just 'kwrite' or 'kwrite-4.5.5' is the
best you can hope for.

(IMHO, mageia-app-db should be more versatile in the way it searches
bug reports, note that almost at any given point in time there'll be
reports that haven't been triaged yet, and so can have an empty or a
wrong content in the RPM Package field)


And about it being hard to find the name of the package, it depends,
do you think users reporting a bug read? if they read the little
paragraph under the Source RPM field here:
https://qa.mandriva.com/enter_bug.cgi?product=Mandriva%20Linuxformat=guided
you'll find that it states exactly how to find the src.rpm name :)

The point is, such things come with time and experience with bug
reporting, I don't expect a user to get it right the first time, but
if he still doesn't get it right with his say 15th bug report, then he
doesn't take enough care when filing the report and I can assure
you by that time he'll have been notified more than once about what
should be done (by triage team members, devs, package maintainers...
etc).

-- 
Ahmad Samir

Re: [Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

On 23 December 2010 01:43, Samuel Verschelde sto...@laposte.net wrote:

 In fact I think Frederic was talking about several versions of the same 
 package, not necessarily several versions of the distribution. However, I 
 don't think we can or should ask people to write down every package version 
 which has the bug.

 We can guess many things automatically, provided the information is of good 
 quality (the RPM/SRPM field always has a complete filename in it, and all 
 affected versions of the distribution are flagged, whatever the way used for 
 that : multivalue field when it'll be possible, whiteboard meanwhile...).

 For those who don't wan't to read everything, example 1 may be enough, I'm 
 just trying to cover several cases, not that every case brings something 
 really important to the discussion. My point in those examples is that we can 
 provide useful information regarding bugs on packages in software managers or 
 mageia-app-db, but that depends on the information present in the bug 
 reports, that's what I'd like this to be taken into account in bug handling 
 processes.


 -- Example 1 : bug in stable release (core/release) + cauldron --

 foo-3.4-1mga2011.0.src.rpm has a bug in Mageia 2011.0 (stable release, the 
 package is in core/release), and the bug is also present in cauldron. We know 
 it is in 2011.0/core/release because we have the exact SRPM name and affected 
 distribution versions in the bug report.

 1) 2011.0/core/release contains foo-3.4-1mga2011.0.src.rpm
 2) 2011.0/core/updates contains foo-3.4-2mga2011.0.src.rpm
 3) 2011.0/core/updates_testing contains foo-3.4-3mga2011.0.src.rpm
 4) 2011.0/core/backports contains foo-3.5-1mga2011.0.src.rpm
 5) 2011.0/core/backports_testing contains foo-3.5-2mga2011.0.src.rpm
 6) cauldron contains foo-3.5-1mga2011.1.src.rpm

 Now suppose we are in mageia-app-db, on each of those SRPMs' page (or on the 
 RPMs pages that have those SRPMs as source RPMs). What can we tell regarding 
 the bug we are talking about ?

 1) bug is present, this is the exact version that has the bug
 2) bug is present, because the bug report is still open
 3) we can't tell, that's a testing package. We can at least say : the 
 current version in core/updates has the following bugs, maybe this testing 
 package fixes them ? Please consult the following bug reports and test
 4) trickier. I would try the following guess : bug is still open in cauldron, 
 so it's probably present in the backport too. However if the bug is fixed in 
 cauldron we can say nothing more than : the version in updates has the bug, 
 cauldron hasn't, maybe the backport also hasn't the bug?.
 5) same as 4)
 6) easy : if cauldron is still mentioned in the bug report (as the version or 
 on the whiteboard), then the bug is still valid. If there was a separate bug 
 report which is closed, then the bug is fixed.

 Of course I assume we don't close a bug as fixed on a stable distribution 
 version if there was no update to fix the bug (update, not backport).


 -- Example 2 : bug in stable release (core/updates) + cauldron --

 foo-3.4-2mga2011.0.src.rpm has a bug in Mageia 2011.0 (stable release, the 
 package is in core/release), and the bug is also present in cauldron.

 Same as example 1, except that we cannot tell if the bug is present in case 
 1) : 2011/core/release
 - either it wasn't and was introduced in an update
 - or it was already there

 What we would do in mageia-app-db is tell an update for this RPM has a the 
 following bug, it may or may not be also present in this package. However in 
 this case few people are still interested in the package in core/release (we 
 may even hide those packages by default when there's an update and keep them 
 only for advanced users).


 -- Example 3 : bug in stable release (core/updates_testing) --

 foo-3.4-3mga2011.0.src.rpm has a bug in Mageia 2011.0 (stable release, the 
 package is in core/updates_testing).

 1) we can't say much, so we'll not show this bug report
 2) we can't say much, so we'll not show this bug report
 3) that's the package which has the bug
 4) not concerned
 5) not concerned
 6) not concerned

 You could say Hey, this example shows nothing useful, and at first I 
 thought the same, but in fact because we know the exact version of package 
 which has the bug (thanks to the RPM/SRPM field + distribution version field) 
 we know we won't bother users about this bug if they consult 1), 2), 4), 5) 
 or 6).


 -- Example 4 : bug in stable release (core/backports) --

 foo-3.5-1mga2011.0.src.rpm has a bug in Mageia 2011.0 (stable release, the 
 package is in core/backports).

 1) we can't say much, so we'll not show this bug report
 2) we can't say much, so we'll not show this bug report
 3) we can't say much, so we'll not show this bug report
 4) that's the package which has the bug
 5) we can't tell, that's a testing package. We can at least say : the 
 current version in core/backports has the following bugs, maybe this 

Re: [Mageia-dev] Proposal for bugzilla

[Michael scherer]

On Wed, Dec 22, 2010 at 11:34:35PM +0100, Samuel Verschelde wrote:
 Le mercredi 22 décembre 2010 21:25:39, Michael scherer a écrit :
  
  On Wed, Dec 22, 2010 at 01:55:02PM +0100, Frederic Janssens wrote:
   On 2010-12-22, Michael Scherer m...@zarb.org wrote:
Le mercredi 22 décembre 2010 à 00:32 +0100, Frederic Janssens a écrit :
   On https://qa.mandriva.com/ anything goes.
   To permit consistent searches I think we should standardise.
   The aim would to be to as specific as needed but not more;
   as far as I know that would be :
   
   name-version-release
   
   unless the bug is architecture specific, where we would have :
   
   name-version-release.architecture
  
  There is already a architecture field, afaik, as well as a version field,
  no ?
  
  ( I didn't check as I refuse to enter my password over a insecured http 
  session ).
  
  And I think that giving rpm ( and not srpm ) will make search a little bit 
  complex
  in some corner cases ( can will also cause problem for the next point ). 
  
 
 So you think the (S)RPM field should only contain SRPM filenames ?

No, just the srpm name. 
At least from a data point of view.
 
 If yes, I agree with that, because as Frederic stated above, in current 
 Mandriva bugzilla, there's no enforced rule for that. You can put 
 anything in the field, and you often end up with rpm filenames, or 
 simple package names (e.g. virtualbox).
 
 However asking bug reporters to know the SRPM is too much, so this rule 
 can only be enforced on Packagers and Triage Team side I think. This is 
 already how it works on qa.mandriva.com : if you know the SRPM, you put 
 it, if not someone will triage and do it for you.

Well, that's more a UI question, and so it should be decoralated from the 
way we store data in the DB.  ( now, it may be hard to achieve, but I am sure 
that templates + ajax could do miracle, like enter the name of rpm here and
have it searched with js to fill the proper input ). 

-- 
Michael Scherer

Re: [Mageia-dev] Proposal for bugzilla

[Samuel Verschelde]

Le jeudi 23 décembre 2010 15:29:15, Ahmad Samir a écrit :
 
 On 23 December 2010 01:43, Samuel Verschelde sto...@laposte.net wrote:
 
  In fact I think Frederic was talking about several versions of the same 
  package, not necessarily several versions of the distribution. However, I 
  don't think we can or should ask people to write down every package version 
  which has the bug.
 
  We can guess many things automatically, provided the information is of good 
  quality (the RPM/SRPM field always has a complete filename in it, and all 
  affected versions of the distribution are flagged, whatever the way used 
  for that : multivalue field when it'll be possible, whiteboard 
  meanwhile...).
 
  For those who don't wan't to read everything, example 1 may be enough, I'm 
  just trying to cover several cases, not that every case brings something 
  really important to the discussion. My point in those examples is that we 
  can provide useful information regarding bugs on packages in software 
  managers or mageia-app-db, but that depends on the information present in 
  the bug reports, that's what I'd like this to be taken into account in bug 
  handling processes.
 
  [...]
 
 This thread is about bugzilla configuration and setup not mageia-app-db...
 

I'm quite puzzled by this answer. I was talking about the impacts of bugzilla 
configuration on what useful information we will be able to give to users 
outside of bugzilla. Apparently this is off-topic.

Regards

Samuel Verschelde

Re: [Mageia-dev] Proposal for bugzilla

[Michael scherer]

On Thu, Dec 23, 2010 at 12:43:23AM +0100, Samuel Verschelde wrote:
 Le mercredi 22 décembre 2010 20:34:18, Ahmad Samir a écrit :
  
  On 22 December 2010 21:25, Frederic Janssens fja...@gmail.com wrote:
   On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote:
   On 22 December 2010 18:37, Frederic Janssens fja...@gmail.com wrote:
   On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote:
   On 22 December 2010 01:32, Frederic Janssens fja...@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'.
  
  
  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 Frederic was talking about several versions of the same 
 package, not necessarily several versions of the distribution. However, 
 I don't think we can or should ask people to write down every package 
 version which has the bug. 
 
 We can guess many things automatically, provided the information is of 
 good quality (the RPM/SRPM field always has a complete filename in it, 
 and all affected versions of the distribution are flagged, whatever the 
 way used for that : multivalue field when it'll be possible, whiteboard 
 meanwhile...).
 
 For those who don't wan't to read everything, example 1 may be enough, 
 I'm just trying to cover several cases, not that every case brings 
 something really important to the discussion. My point in those examples 
 is that we can provide useful information regarding bugs on packages in 
 software managers or mageia-app-db, but that depends on the information 
 present in the bug reports, that's what I'd like this to be taken into 
 account in bug handling processes. 

What about using the changelog for signalling what bug
have been closed ?

Something like what is done by debian 
http://www.debian.org/doc/developers-reference/pkgs.html#upload-bugfix

-- 
Michael Scherer

Re: [Mageia-dev] Proposal for bugzilla

[Samuel Verschelde]

Le jeudi 23 décembre 2010 20:44:14, Michael scherer a écrit :
 On Wed, Dec 22, 2010 at 11:34:35PM +0100, Samuel Verschelde wrote:
  Le mercredi 22 décembre 2010 21:25:39, Michael scherer a écrit :
   On Wed, Dec 22, 2010 at 01:55:02PM +0100, Frederic Janssens wrote:
On 2010-12-22, Michael Scherer m...@zarb.org wrote:
 Le mercredi 22 décembre 2010 à 00:32 +0100, Frederic Janssens a 
écrit :
On https://qa.mandriva.com/ anything goes.
To permit consistent searches I think we should standardise.
The aim would to be to as specific as needed but not more;
as far as I know that would be :

name-version-release

unless the bug is architecture specific, where we would have :

name-version-release.architecture
   
   There is already a architecture field, afaik, as well as a version
   field, no ?
   
   ( I didn't check as I refuse to enter my password over a insecured http
   session ).
   
   And I think that giving rpm ( and not srpm ) will make search a little
   bit complex in some corner cases ( can will also cause problem for the
   next point ).
  
  So you think the (S)RPM field should only contain SRPM filenames ?
 
 No, just the srpm name.
 At least from a data point of view.
 
  If yes, I agree with that, because as Frederic stated above, in current
  Mandriva bugzilla, there's no enforced rule for that. You can put
  anything in the field, and you often end up with rpm filenames, or
  simple package names (e.g. virtualbox).
  
  However asking bug reporters to know the SRPM is too much, so this rule
  can only be enforced on Packagers and Triage Team side I think. This is
  already how it works on qa.mandriva.com : if you know the SRPM, you put
  it, if not someone will triage and do it for you.
 
 Well, that's more a UI question, and so it should be decoralated from the
 way we store data in the DB.  ( now, it may be hard to achieve, but I am
 sure that templates + ajax could do miracle, like enter the name of rpm
 here and have it searched with js to fill the proper input ).

I remember some years ago you could choose the exact version of the package 
for which you reported a bug, from a list. I agree that improving the UI side 
helpers could be useful.

Regards

Samuel Verschelde

Re: [Mageia-dev] Proposal for bugzilla

[Samuel Verschelde]

Le jeudi 23 décembre 2010 20:51:21, Michael scherer a écrit :
 On Thu, Dec 23, 2010 at 12:43:23AM +0100, Samuel Verschelde wrote:
  
  We can guess many things automatically, provided the information is of
  good quality (the RPM/SRPM field always has a complete filename in it,
  and all affected versions of the distribution are flagged, whatever the
  way used for that : multivalue field when it'll be possible, whiteboard
  meanwhile...).
  
  For those who don't wan't to read everything, example 1 may be enough,
  I'm just trying to cover several cases, not that every case brings
  something really important to the discussion. My point in those examples
  is that we can provide useful information regarding bugs on packages in
  software managers or mageia-app-db, but that depends on the information
  present in the bug reports, that's what I'd like this to be taken into
  account in bug handling processes.
 
 What about using the changelog for signalling what bug
 have been closed ?
 
 Something like what is done by debian
 http://www.debian.org/doc/developers-reference/pkgs.html#upload-bugfix

That's interesting, indeed, even if I think we are more interested in what 
bugs are still open rather than in what packages it was present previously.

The main reason for that is that we only have the latests versions in the 
repositories. Knowing which bugs they don't have anymore seems less important 
than knowing which bugs they have now, but I may be wrong about this specific 
user need.

However I keep your suggestion somewhere in my mind :)

Regards

Samuel Verschelde 

Re: [Mageia-dev] Proposal for bugzilla

[Maarten Vanraes]

Op donderdag 23 december 2010 22:23:56 schreef Ahmad Samir:
 On 23 December 2010 22:01, Samuel Verschelde sto...@laposte.net wrote:
  I remember some years ago you could choose the exact version of the
  package for which you reported a bug, from a list. I agree that
  improving the UI side helpers could be useful.
  
  Regards
  
  Samuel Verschelde
 
 As was said by dmorgan, listing each SRPM slowed down bugzilla a lot;
 the distro has a lot of SRPMS...

an ajax search is better; it doesn't add much and only gets searched if you 
enter at least 2 chars, or something like that.

if such an ajax is wanted, i can write that if i can use app-mageia-db or 
similar as a list.

Re: [Mageia-dev] Proposal for bugzilla

[Dexter Morgan]

On Thu, Dec 23, 2010 at 11:22 PM, Ahmad Samir ahmadsamir3...@gmail.com wrote:
 On 24 December 2010 00:13, Maarten Vanraes maarten.vanr...@gmail.com wrote:
 Op donderdag 23 december 2010 22:23:56 schreef Ahmad Samir:
 On 23 December 2010 22:01, Samuel Verschelde sto...@laposte.net wrote:
  I remember some years ago you could choose the exact version of the
  package for which you reported a bug, from a list. I agree that
  improving the UI side helpers could be useful.
 
  Regards
 
  Samuel Verschelde

 As was said by dmorgan, listing each SRPM slowed down bugzilla a lot;
 the distro has a lot of SRPMS...

 an ajax search is better; it doesn't add much and only gets searched if you
 enter at least 2 chars, or something like that.

 if such an ajax is wanted, i can write that if i can use app-mageia-db or
 similar as a list.


 If the user doesn't know how to find the package info (rpm -q
 packagname), no auto-complete is going to help much, he'll just pick
 one of them randomly (top of the list, or bottom of the list). It's
 not much to ask for rpm -q output...

 --
 Ahmad Samir


and this method is deprecated ( i mean the big list ) because this
slow down too much the server.

Re: [Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

On 14 December 2010 18:05, Dexter Morgan dmorga...@gmail.com wrote:
 hello,

 now that we have a working bugzilla we need to have a working layout.

 i created a wiki page presenting what could be done.
 http://mageia.org/wiki/doku.php?id=bugzilla

 I would like to have your input to let us able to provide a bugzilla really 
 soon


 In the bugreport creation we were thinking of using the mdv way or the
 fedora way.


 Fedora way is to add all srpms in the componment field but there is 2
 pbs with this way :

 - Users don't know what is a rpms ( like what is the srpms for kwrite )
 - This slow down the bugzilla too much


I am most familiar with the layout at qa.mandriva.com, so I think it's
good to start with it and modify things as needed.

- I think we should have two 'Products' (for now), Mageia and Websites.

- Under the 'Product: Mageia' the Version field (1.0, 1.1, 2.0,
Cauldron... etc) specifies the release the bug report affects (with a
whiteboard field to state if the bug affects more than one release (at
least for now)).

- The Components should be:
  - Documentation
  - Installation
  - RPM packages
  - New Packages requests
  - Release Media
  - Security
  - Translations

Note that I dropped:
 - Kernel, as it's just still an rpm package and will be assigned
properly based on the RPM Package field
 - Hardware, we won't fix bugs in hardware, we'll fix bugs in the
software handling the hardware (and it was seldom used in the past
anyway)


- An Architecture field

- Source RPM / RPM Package

- Url field, for putting links to upstream bug reports in a clear place

- Summary

- Description

- Severity and Priority fields

See here for a picture of what I have in mind:
https://qa.mandriva.com/enter_bug.cgi?product=Mandriva%20Linuxformat=guided

-- 
Ahmad Samir

Re: [Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

On 22 December 2010 01:32, Frederic Janssens fja...@gmail.com wrote:
 On Wed, Dec 15, 2010 at 17:07, Michael Scherer m...@zarb.org wrote:

 Le mardi 14 décembre 2010 à 17:05 +0100, Dexter Morgan a écrit :
  I would like to have your input to let us able to provide a bugzilla 
  really soon

 So if I am not wrong, in bugzilla, we have :
 - products
 - component, contained in products
 - and various field, per bug,

 and the way we organize everything will impact the layout.


 Yes.

 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).

 But, as the configuration must be modified anyway, I have been
 thinking about what fields we need.

 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.

 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

 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).

 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).

 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
affects Cauldron, well, Cauldron users are supposed to be
fireproof-ready, so they do read bug reports (or skim through them).

 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

Re: [Mageia-dev] Proposal for bugzilla

[Frederic Janssens]

On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote:
 On 22 December 2010 01:32, Frederic Janssens fja...@gmail.com wrote:
 On Wed, Dec 15, 2010 at 17:07, Michael Scherer m...@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'.
(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']



 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.



 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 ?



 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
 

Re: [Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

On 22 December 2010 18:37, Frederic Janssens fja...@gmail.com wrote:
 On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote:
 On 22 December 2010 01:32, Frederic Janssens fja...@gmail.com wrote:
 On Wed, Dec 15, 2010 at 17:07, Michael Scherer m...@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 

Re: [Mageia-dev] Proposal for bugzilla

[Renaud MICHEL]

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'.
 
 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.

-- 
Renaud Michel

Re: [Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

On 22 December 2010 21:25, Frederic Janssens fja...@gmail.com wrote:
 On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote:
 On 22 December 2010 18:37, Frederic Janssens fja...@gmail.com wrote:
 On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote:
 On 22 December 2010 01:32, Frederic Janssens fja...@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'.


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

Re: [Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

On 22 December 2010 21:30, Renaud MICHEL r.h.michel+mag...@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'.

 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.

 --
 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.

-- 
Ahmad Samir

Re: [Mageia-dev] Proposal for bugzilla

[Maarten Vanraes]

Op woensdag 22 december 2010 20:38:06 schreef Ahmad Samir:
 On 22 December 2010 21:30, Renaud MICHEL r.h.michel+mag...@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'.
  
  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.
  
  --
  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...

Re: [Mageia-dev] Proposal for bugzilla

[Ahmad Samir]

On 22 December 2010 21:45, Maarten Vanraes maarten.vanr...@gmail.com wrote:
 Op woensdag 22 december 2010 20:38:06 schreef Ahmad Samir:
 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...


In two years, I probably never used the RPM Package as a search
criteria (I don't have any statistics many people use it, my guess
would be a small number); I usually search in the Comments with
Contains all of the words or Contains all of the words/strings
(not just in mdv bugzilla, but in any bugzilla I use, some of them
enable searching in the bug Summary); so you search for firefox
crash bookmarks or firefox crash move tab or firefox hang quit, I
think that's what most users will do as the RPM Package is a bit
hidden at the bottom.

IMHO, this is better, because a GTK2+ bug could affect a lot of GTK2+
apps, I don't think it's ideal to list every single affected package
in the RPM Package field. The same goes for kdelibs or perl or
python or ffmpeg... etc.

-- 
Ahmad Samir

Re: [Mageia-dev] Proposal for bugzilla

[Michael scherer]

On Wed, Dec 22, 2010 at 01:55:02PM +0100, Frederic Janssens wrote:
 On 2010-12-22, Michael Scherer m...@zarb.org wrote:
  Le mercredi 22 décembre 2010 à 00:32 +0100, Frederic Janssens a écrit :
  On Wed, Dec 15, 2010 at 17:07, Michael Scherer m...@zarb.org wrote:
  
   Le mardi 14 décembre 2010 à 17:05 +0100, Dexter Morgan a écrit :
I would like to have your input to let us able to provide a bugzilla
really soon
  
   So if I am not wrong, in bugzilla, we have :
   - products
   - component, contained in products
   - and various field, per bug,
  
   and the way we organize everything will impact the layout.
  
 
  Yes.
 
  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/).
 
  What about component not related to rpm ?
 
 The 'RPM Package' field would be left blank.
 (usually many fields are left blank)

That's quite useless clutter in this case :/
 
 
  And do you mean srpm or rpm ?
 
 On https://qa.mandriva.com/ anything goes.
 To permit consistent searches I think we should standardise.
 The aim would to be to as specific as needed but not more;
 as far as I know that would be :
 
 name-version-release
 
 unless the bug is architecture specific, where we would have :
 
 name-version-release.architecture

There is already a architecture field, afaik, as well as a version field,
no ?

( I didn't check as I refuse to enter my password over a insecured http session 
).

And I think that giving rpm ( and not srpm ) will make search a little bit 
complex
in some corner cases ( can will also cause problem for the next point ). 

 
  We should also take in account package naming change.
 
 which change?

Well, when a rpm change name, rename it in the field to be the new name, so not 
all bugs 
are lost.

-- 
Michael Scherer

Re: [Mageia-dev] Proposal for bugzilla

[Michael scherer]

On Wed, Dec 22, 2010 at 09:34:18PM +0200, Ahmad Samir wrote:
 On 22 December 2010 21:25, Frederic Janssens fja...@gmail.com wrote:
  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).

Not before 4.2.X, according to meeting logs :
http://meetbot.mageia.org/mageia-meeting/2010/mageia-meeting.2010-11-08-19.06.log.html#l-102

-- 
Michael Scherer

Re: [Mageia-dev] Proposal for bugzilla

[andre999]

Dexter Morgan a écrit :


hello,

now that we have a working bugzilla we need to have a working layout.

i created a wiki page presenting what could be done.
http://mageia.org/wiki/doku.php?id=bugzilla

I would like to have your input to let us able to provide a bugzilla really soon


In the bugreport creation we were thinking of using the mdv way or the
fedora way.


Fedora way is to add all srpms in the componment field but there is 2
pbs with this way :

-  Users don't know what is a rpms ( like what is the srpms for kwrite )
-  This slow down the bugzilla too much


Reaction from an end-user that has filed/commented/viewed a lot of bug 
reports.


- I like the idea of separating
-- main bug reports.
All releases together.  A lot of end-users are not very aware of the 
version/release of the software with the bug until they are well into 
the reporting process.  So selecting the release would be better delayed 
to the bug report entry page.
Plus the idea of eventually having bugs applying to multiple releases 
(mentioned on another post) sounds good, as well.


-- documentation
Tends to be reported/corrected by different people than software bugs.

-- localisation (maybe combined with documentation ?)
Also tends to be reported by different people than software bugs, and 
corrected by translators.


-- cauldron

- Better to avoid listing .srpm's.  Most end-users filing bug reports 
have no idea what they are.  So no point in slowing down bugzilla for that.
And from the .rpm, packagers/developers will be able to find the .srpm 
quickly enough.


- The idea of a multiline .rpm field (mentioned on another post) seems 
an excellent idea.  Better to list all related .rpm's in one location 
than putting additional .rpms into the description and/or comment 
fields.  (Not only for mageia-app-db.)


my 2 cents :)

Re: [Mageia-dev] Proposal for bugzilla

[andre999]

Maarten Vanraes a écrit :


Op woensdag 22 december 2010 20:38:06 schreef Ahmad Samir:

On 22 December 2010 21:30, Renaud MICHELr.h.michel+mag...@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é

Re: [Mageia-dev] Proposal for bugzilla

[Maarten Vanraes]

Op woensdag 22 december 2010 22:30:00 schreef andre999:
 Dexter Morgan a écrit :
  hello,
  
  now that we have a working bugzilla we need to have a working layout.
  
  i created a wiki page presenting what could be done.
  http://mageia.org/wiki/doku.php?id=bugzilla
  
  I would like to have your input to let us able to provide a bugzilla
  really soon
  
  
  In the bugreport creation we were thinking of using the mdv way or the
  fedora way.
  
  
  Fedora way is to add all srpms in the componment field but there is 2
  pbs with this way :
  
  -  Users don't know what is a rpms ( like what is the srpms for kwrite )
  -  This slow down the bugzilla too much
 
 Reaction from an end-user that has filed/commented/viewed a lot of bug
 reports.
 
 - I like the idea of separating
 -- main bug reports.
 All releases together.  A lot of end-users are not very aware of the
 version/release of the software with the bug until they are well into
 the reporting process.  So selecting the release would be better delayed
 to the bug report entry page.
 Plus the idea of eventually having bugs applying to multiple releases
 (mentioned on another post) sounds good, as well.
 
 -- documentation
 Tends to be reported/corrected by different people than software bugs.

good call

 -- localisation (maybe combined with documentation ?)
 Also tends to be reported by different people than software bugs, and
 corrected by translators.

again good call

 -- cauldron

i doubt this

 - Better to avoid listing .srpm's.  Most end-users filing bug reports
 have no idea what they are.  So no point in slowing down bugzilla for that.
 And from the .rpm, packagers/developers will be able to find the .srpm
 quickly enough.

actually, the triage team finds this alot quicker than package maintainers, 
they often only care about their own package, and if it's not assigned to 
their package they won't be looking for it.

i do agree that users often have no clue of what specific component is 
responsible for what, and they often get it wrong if they try.

 - The idea of a multiline .rpm field (mentioned on another post) seems
 an excellent idea.  Better to list all related .rpm's in one location
 than putting additional .rpms into the description and/or comment
 fields.  (Not only for mageia-app-db.)
 
 my 2 cents :)

Re: [Mageia-dev] Proposal for bugzilla

[Samuel Verschelde]

Le mercredi 22 décembre 2010 22:58:44, andre999 a écrit :
 
 Maarten Vanraes a écrit :
 
  Op woensdag 22 december 2010 20:38:06 schreef Ahmad Samir:
  On 22 December 2010 21:30, Renaud MICHELr.h.michel+mag...@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.

No need for a multiline field. If we agree that the field, by convention, can 
contain one rpm name (common case) or more, separated by commas for example, 
then it wont add complexity over the initial proposal from Ahmad and would 
still allow people to flag more RPMs if they want.

From the bug solving point of view, this would not add much benefit, but for 
users it may bring some useful information, for example in mageia-app-db. 
Indeed, like it was said earlier, if the problem shows in package A but is in 
fact a bug in package B, it's still useful to have package A mentioned so that 
we can say, on the package's page in mageia-app-db Hey, there's a known open 
bug for this package.


Regards

Samuel Verschelde

Re: [Mageia-dev] Proposal for bugzilla

[Maarten Vanraes]

Op woensdag 22 december 2010 23:25:16 schreef Samuel Verschelde:
 Le mercredi 22 décembre 2010 22:58:44, andre999 a écrit :
  Maarten Vanraes a écrit :
   Op woensdag 22 december 2010 20:38:06 schreef Ahmad Samir:
   On 22 December 2010 21:30, Renaud MICHELr.h.michel+mag...@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.
 
 No need for a multiline field. If we agree that the field, by convention,
 can contain one rpm name (common case) or more, separated by commas for
 example, then it wont add complexity over the initial proposal from Ahmad
 and would still allow people to flag more RPMs if they want.
 
 From the bug solving point of view, this would not add much benefit, but
 for users it may bring some useful information, for example in
 mageia-app-db. Indeed, like it was said earlier, if the problem shows in
 package A but is in fact a bug in package B, it's still useful to have
 package A mentioned so that we can say, on the package's page in
 mageia-app-db Hey, there's a known open bug for this package.
 
 
 Regards
 
 Samuel Verschelde


good compromise

Re: [Mageia-dev] Proposal for bugzilla

[Samuel Verschelde]

Le mercredi 22 décembre 2010 21:25:39, Michael scherer a écrit :
 
 On Wed, Dec 22, 2010 at 01:55:02PM +0100, Frederic Janssens wrote:
  On 2010-12-22, Michael Scherer m...@zarb.org wrote:
   Le mercredi 22 décembre 2010 à 00:32 +0100, Frederic Janssens a écrit :
   On Wed, Dec 15, 2010 at 17:07, Michael Scherer m...@zarb.org wrote:
   
Le mardi 14 décembre 2010 à 17:05 +0100, Dexter Morgan a écrit :
 I would like to have your input to let us able to provide a bugzilla
 really soon
   
So if I am not wrong, in bugzilla, we have :
- products
- component, contained in products
- and various field, per bug,
   
and the way we organize everything will impact the layout.
   
  
   Yes.
  
   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/).
  
   What about component not related to rpm ?
  
  The 'RPM Package' field would be left blank.
  (usually many fields are left blank)
 
 That's quite useless clutter in this case :/
  
  
   And do you mean srpm or rpm ?
  
  On https://qa.mandriva.com/ anything goes.
  To permit consistent searches I think we should standardise.
  The aim would to be to as specific as needed but not more;
  as far as I know that would be :
  
  name-version-release
  
  unless the bug is architecture specific, where we would have :
  
  name-version-release.architecture
 
 There is already a architecture field, afaik, as well as a version field,
 no ?
 
 ( I didn't check as I refuse to enter my password over a insecured http 
 session ).
 
 And I think that giving rpm ( and not srpm ) will make search a little bit 
 complex
 in some corner cases ( can will also cause problem for the next point ). 
 

So you think the (S)RPM field should only contain SRPM filenames ?

If yes, I agree with that, because as Frederic stated above, in current 
Mandriva bugzilla, there's no enforced rule for that. You can put anything in 
the field, and you often end up with rpm filenames, or simple package names 
(e.g. virtualbox).

However asking bug reporters to know the SRPM is too much, so this rule can 
only be enforced on Packagers and Triage Team side I think. This is already how 
it works on qa.mandriva.com : if you know the SRPM, you put it, if not someone 
will triage and do it for you.

Ahmad, would there be a problem in enforcing such a policy (i.e. SRPM field 
should be empty or contain a valid SRPM name ? Where valid means looks like 
the name of a SRPM) ? 

Regards

Samuel Verschelde

Re: [Mageia-dev] Proposal for bugzilla

[Samuel Verschelde]

Le mercredi 22 décembre 2010 20:34:18, Ahmad Samir a écrit :
 
 On 22 December 2010 21:25, Frederic Janssens fja...@gmail.com wrote:
  On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote:
  On 22 December 2010 18:37, Frederic Janssens fja...@gmail.com wrote:
  On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote:
  On 22 December 2010 01:32, Frederic Janssens fja...@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'.
 
 
 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 Frederic was talking about several versions of the same 
package, not necessarily several versions of the distribution. However, I don't 
think we can or should ask people to write down every package version which has 
the bug. 

We can guess many things automatically, provided the information is of good 
quality (the RPM/SRPM field always has a complete filename in it, and all 
affected versions of the distribution are flagged, whatever the way used for 
that : multivalue field when it'll be possible, whiteboard meanwhile...).

For those who don't wan't to read everything, example 1 may be enough, I'm just 
trying to cover several cases, not that every case brings something really 
important to the discussion. My point in those examples is that we can provide 
useful information regarding bugs on packages in software managers or 
mageia-app-db, but that depends on the information present in the bug reports, 
that's what I'd like this to be taken into account in bug handling processes. 


-- Example 1 : bug in stable release (core/release) + cauldron --

foo-3.4-1mga2011.0.src.rpm has a bug in Mageia 2011.0 (stable release, the 
package is in core/release), and the bug is also present in cauldron. We know 
it is in 2011.0/core/release because we have the exact SRPM name and affected 
distribution versions in the bug report.

1) 2011.0/core/release contains foo-3.4-1mga2011.0.src.rpm
2) 2011.0/core/updates contains foo-3.4-2mga2011.0.src.rpm
3) 2011.0/core/updates_testing contains foo-3.4-3mga2011.0.src.rpm
4) 2011.0/core/backports contains foo-3.5-1mga2011.0.src.rpm
5) 2011.0/core/backports_testing contains foo-3.5-2mga2011.0.src.rpm
6) cauldron contains foo-3.5-1mga2011.1.src.rpm

Now suppose we are in mageia-app-db, on each of those SRPMs' page (or on the 
RPMs pages that have those SRPMs as source RPMs). What can we tell regarding 
the bug we are talking about ?

1) bug is present, this is the exact version that has the bug
2) bug is present, because the bug report is still open
3) we can't tell, that's a testing package. We can at least say : the current 
version in core/updates has the following bugs, maybe this testing package 
fixes them ? Please consult the following bug reports and test
4) trickier. I would try the following guess : bug is still open in cauldron, 
so it's probably present in the backport too. However if the bug is fixed in 
cauldron we can say nothing more than : the version in updates has the bug, 
cauldron hasn't, maybe the backport also hasn't the bug?. 
5) same as 4)
6) easy : if cauldron is still mentioned in the bug report (as the version or 
on the whiteboard), then the bug is still valid. If there was a separate bug 
report which is closed, then the bug is fixed. 

Of course I assume we don't close a bug as fixed on a stable distribution 
version if there was no update to fix the bug (update, not backport).


-- Example 2 : bug in stable release (core/updates) + cauldron --

foo-3.4-2mga2011.0.src.rpm has a bug in Mageia 2011.0 (stable release, the 
package is in core/release), and the bug is also present in cauldron.

Same as 

Re: [Mageia-dev] Proposal for bugzilla

[Frederic Janssens]

On Wed, Dec 15, 2010 at 17:07, Michael Scherer m...@zarb.org wrote:

 Le mardi 14 décembre 2010 à 17:05 +0100, Dexter Morgan a écrit :
  I would like to have your input to let us able to provide a bugzilla really 
  soon

 So if I am not wrong, in bugzilla, we have :
 - products
 - component, contained in products
 - and various field, per bug,

 and the way we organize everything will impact the layout.


Yes.

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/).

But, as the configuration must be modified anyway, I have been
thinking about what fields we need.

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.
For the same reason, the way the rpms are mentioned should be 'standardised',
as the search done by bugzilla can only be litteral.

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)?

Perhaps also an 'Upstream' field which would, eventually, indicate
where that bug is filed upstream.

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)

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

Re: [Mageia-dev] Proposal for bugzilla

[Michael Scherer]

Le mardi 14 décembre 2010 à 17:05 +0100, Dexter Morgan a écrit :
 hello,
 
 now that we have a working bugzilla we need to have a working layout.
 
 I created a wiki page presenting what could be done.
 http://mageia.org/wiki/doku.php?id=bugzilla
 
 I would like to have your input to let us able to provide a bugzilla really 
 soon

So if I am not wrong, in bugzilla, we have :
- products
- component, contained in products
- and various field, per bug, 

and the way we organize everything will impact the layout. 

And for now, we are just talking of :
- distributions 
- website 

this lead me to 3 questions, regarding the proposal potential layout
at the end of the page :

- if we do have 1 product per distribution, doesn't that mean that we
will have a lot of product in 5 years ?  While we can filter on the
first page and show only supported distros, this would be a quite long
entry on the bug page ( show_bug.cgi ) if we want to change the product.

- bugzilla cannot fill bugs for multiple releases, but AFAIK, something
like this is planned in the future ( 4.X with X2, as said on
http://meetbot.mageia.org/mageia-meeting/2010/mageia-meeting.2010-11-08-19.06.log.html#l-147
 ). What would be the requirement of such setup, what is planned on bugzilla ?

- what about requests that are not for website, like generic sysadmin
request, or maybe community process, etc ?  

-- 
Michael Scherer