Bonjour, Pour ceux qui font de la QA, il y a eu une décision prise entre dev et équipe QA concernant les MAB et les priorités, je vous la traduit ici (elle était pas claire pour moi) : ----------------------------------------- Tous les bugs qui sont sur NEW avec la priorité highest doivent aussi être dans les MAB et tous les bugs sur NEW dans les MAB doivent avoir la priorité highest.
Les instructions sur le wiki ont été mises à jour en ce sens, définir "priority: highest" quand un bug est ajouté au MAB. Pour l'équipe QA, cela signifie deux choses: ====Court terme==== Pour conserver l'équivalence highest=MAB claire, des vérifications régulières (toutes les semaines ?) des bugs qui ont la priorité: highest et ne sont pas des MAB sont nécessaires. Ces bugs peuvent être vus comme "proprosition de MAB" et être : - soit promus comme MAB par la procédure habituelle, - soit rejetés et donc avoir leur priorité: high Quelqu'un se porte-t-il volontaire pour cette tâche ? Si oui, il serait également intéressant : - de savoir combien de bugs il y a chaque semaine - quelle est leur qualité (du type : combien sont de bons MAB ? combien sont bien triés ?) ===à long terme=== Si l'activité à court terme ci-dessus montre que le nombre de faux positifs est bas, la QA et le dev pourrait envisager d'utiliser simplement la priorité highest directement. La QA devrait alors s'assurer que le nombre de bugs reste idéalement entre 50-100 (le nombre exact sera discuté à l'ESC). Elle le ferait par exemple en observant les bugs qui ont été ajoutés avec la priorité highest ces dernières semaines (notez que la liste est brouillé à cause des récentes modifications) https://bugs.freedesktop.org/buglist.cgi?priority=highest&list_id=383855&resolution=---&chfieldto=Now&query_format=advanced&chfield=priority&chfieldfrom=-7d&bug_status=NEW&product=LibreOffice Les dev feront simplement une requête sur les bugs avec la priorité highest, ou si cela fait trop de bruit dû au fait que la QA n'a pas fait ce travail de vérification, seuls ceux qui ont plus de 7 jours (et donc déjà examinés par la QA) https://bugs.freedesktop.org/buglist.cgi?priority=highest&f1=priority&list_id=383863&o1=changedafter&resolution=---&n1=1&query_format=advanced&bug_status=NEW&v1=-7d&product=LibreOffice -------------------------------------------- Voilà, n'hésitez pas si vous avez des questions. Je pense qu'à terme cela permettrai de faire disparaître les MAB (je trouve que ces listes sont très difficile à évaluer). Message original ci-dessous À bientôt Sophie -------- Message original -------- Sujet: MABs and priority (was: minutes of ESC call ...) Date : Fri, 17 Jan 2014 12:01:21 +0100 De : Bjoern Michaelsen <bjoern.michael...@canonical.com> Pour : Michael Meeks <michael.me...@collabora.com> Copie à : Libreoffice-qa <libreoffice...@lists.freedesktop.org>, libreoffice-dev <libreoff...@lists.freedesktop.org> Hi, On Thu, Jan 16, 2014 at 06:21:48PM +0000, Michael Meeks wrote: > + All Most Annoying Bugs -> priority Highest (Bjoern) This is done now too, so right now, all NEW bugs(*) with priority highest should also block a MAB and all NEW bugs blocking a MAB should be priority highest. I updated the MAB instructions to include setting "priority: highest" when adding a bug to MAB. for QA, this means two things, one short term, one long term. == short term == To keep the highest=MAB equivalence clean, some regular (weekly?) checking for bugs that are priority:highest and not a MAB would be needed. Such bugs could be seen as "proposed MABs" and either be: - promoted to a MAB with the usual procedure (rationale etc.) - or respectfully rejected and bumped to priority:high Someone volunteering for this task? If so, it would be interesting: - how many such bugs there are each week - what is their quality (as in: how many are good MABs? how many are well triaged?) == long term == If the above short term activity show that the number of false positives is low, QA and development might investigate simply using priority highest directly. QA would then need make sure the total number of priority:highest bugs is ideally somewhere between 50-100 (exact number would be discussed on the ESC). It would do so by watching for example the bugs that were added to priority:highest in the last week with a query like this(**): https://bugs.freedesktop.org/buglist.cgi?priority=highest&list_id=383855&resolution=---&chfieldto=Now&query_format=advanced&chfield=priority&chfieldfrom=-7d&bug_status=NEW&product=LibreOffice Development would simply query for bugs with priority highest, or, if that has to much noise by stuff not sanity checked by the QA, only those bugs in priority:highest that have been in that state for more than 7 days (and thus likely checked by QA), e.g.: https://bugs.freedesktop.org/buglist.cgi?priority=highest&f1=priority&list_id=383863&o1=changedafter&resolution=---&n1=1&query_format=advanced&bug_status=NEW&v1=-7d&product=LibreOffice So, lets see how this evolves! Personally, I would love to see us move away from the MAB tracker bug patchwork solution to something simpler and cleaner. Best, Bjoern (*) Unresolved bugs are mostly uninteresting for tracking MABs, but while checking for this, I found a few unresolved MAB that I missed to put in priority highest because they where not in NEW: - 2 NEEDINFO - 2 ASSIGNED - 11 REOPENED I would assume the assigned ones to resolve themselves soonish. The needinfo ones seem a bit dubious to me: A bug that isnt completely triaged doesnt seem like a good MAB. We will see what happens to the REOPENED ones -- the high count of them seems curious. (**) Note that this query is currently providing so many results because of the bulk move. _______________________________________________ LibreOffice mailing list libreoff...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Envoyez un mail à qa+unsubscr...@fr.libreoffice.org pour savoir comment vous désinscrire Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/qa/ Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être supprimés