[Mageia-dev] Proposal for bugzilla

Thu Dec 23 21:10:19 CET 2010

Le jeudi 23 décembre 2010 15:25:10, Ahmad Samir a écrit :
+> On 23 December 2010 00:34, Samuel Verschelde <stormi at 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 <misc at 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 <misc at 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.
+
+By enforcing a policy, I don't mean necessarily rejecting bad or incomplete 
+values, but rather ensure that triagers and packagers take care of this field 
+and correct it if needed, at least for bugs on stable releases of Mageia.
+
+However misc's remarks about UI-side helpers (autocompletion for example, 
+which would propose only the valid package versions for a given package and a 
+given distribution version) could help here : if filling the field 
+comprehensively becomes easy then it won't be a barrier for unexperienced bug 
+reporters and then being stricter becomes possible.
+
+
+> 
+> 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)
+
+We already plan to be as much versatile as we can be. However like I tried to 
+explain in my long off-topic post, we will have to cope with various levels of 
+quality of information and treat differently bugs concerning just "kwrite" and 
+bugs concerning "kwrite-4.5.5-1mga".
+
+Regards
+
+Samuel Verschelde
+