HowtoTriage

Från Ubuntu Sverige

Hoppa till: navigering, sök
Hur utför man sortering (triage)?

På ett sjukhus utför man en sortering (triage) direkt när en patient kommer in genom akutmottagningens dörrar. Patientens vitala funktioner kontrolleras, hans/hennes status uppskattas och han/hon sorteras in bland alla de andra patienterna som väntar på behandling. Ordet kommer från franskans trier, sortera.

Sorteringen liknar detta förfaringssätt i det att vi bedömer fel för att avgöra om de har tillräckligt med information för att arbetas på och tilldelar dem en prioritet så snart som möjligt. Utan risk för dödsfall.

Ubuntu tar emot en otrolig mängd felrapporter varje dag genom vårt felrapporteringssystem. Var och en av dessa måste läsas, bedömas och sorteras så att den kan bli åtgärdad. Det är här vi skulle behöva din hjälp med att hjälpa till med felrapporter. För en visuell representation av processen bakom felsertering, se dessa vackra flödesscheman.

Innehåll

[redigera] Icke sorterade felrapporter

Felrapporter som inte gått igenom sorteringsprocessen kan hittas via denna länk. När en felrapport inte längre har statusen New kommer den inte att visas i sökningen

Du kan använda Avanced search i buggtracking-systemet för att hitta nya buggar för ett specifikt paket. Gå till Advanced search-sidan för källkodspaketets fel och titta efter:

  • Status: New
  • Importance: Undecided
  • Assigned to: Nobody

[redigera] Nya felrapporter

Varje felrapport är en konversation med felrapportören. Den första kontakten alla rapportörer vanligtvis har med Ubuntu-gemenskapen är genom en felsorterare, som försöker att sätta samman en komplett felrapport. Det är väldigt viktigt att vi ger ett gott intryck, så var artig och försök att använda din bästa engelska.

För att hjälpa till med felsortering måste du kunna hitta nya felrapporter. Som tur är, är detta enkelt. Du kan hitta nya på något av följande tre sätt:

Det första alternativet är det lämpligaste, då du slipper få din e-postlåda fylld med e-post varje gång du läser den.

Om du ansluter till kanalen #ubuntu-bugs-announce, kommer du snart att se meddelanden av den här sorten svischa förbi: 

 New bug: #1 in Ubuntu "Microsoft has a majority market share" [Undecided,New] http://launchpad.net/bugs/1

För att börja väljer du någon av de senaste och öppnar länken i din favoritwebbläsare. Försök att välja ett fel som påverkar program eller delar av det system som du är bekant med själv, eftersom detta kommer att hjälpa dig att besluta hur komplett felrapporten är och hjälper dig att nå stadiet där du kan återskapa felet. Om ingen annan har kommenterat än, då kan den här felrapporten bli din

[redigera] Dubbletter

Många av felrapporterna som registrerats om Ubuntu är faktiskt dubbletter av redan rapporterade fel. Detta kan hända då ett fel som påverkar många har introducerats i Ubuntu, vilket orsakar många rapporter om samma sak från olika användare. Andra gånger kan felrapportörerna sakna kunskap om hur man kollar om samma fel redan blivit rapporterad, eller så kan de ha svårt att avgöra om deras fel är densamma som en annan. Att hitta dessa fel-dubbletter och samla informationen i en felrapport är ett väldigt värdefullt bidrag till gemenskapen.

Fel är dubbletter när de har samma ursprungsorsak. Att avgöra detta är en färdighet som du kommer att snappa upp då du blir mer bekant med ett programpaket eller subsystem. Fel är inte nödvändigtvis dubbletter om de har samma effekt. Till exempel, många olika fel kan orsaka att X inte startar. Att avgöra vilket fel en specifik felrapport hänvisar till är en del av sorteringsprocessen. Om du tvekar, fråga någon annan i BugSquad. Det är förmodligen också vettigt att fråga felrapportören om han/hon kan kolla på den möjliga dubbletten och hjälpa till med beslutet. Felrapportörer är vanligen intresserade att hjälpa till med sina egna felrapporter!

När du först tittar på en ny felrapport, försök att hitta en existerande felrapport i systemet som beskriver den nya. Så här gör du:

  • Klicka på länken "List open bugs" längst ner på felrapportsidan eller
  • Klicka på fliken "Bugs" högst upp på sidan.
    • Båda sätten kommer att visa en lista på buggar om samma paket
  • Kolla efter felrapporter med liknande beskrivning eller relaterade rubriker
  • Om de beskriver samma grundorsak, besluta vilken rapport som ska vara den primära. Detta bör vara den som är mest förståelig och som innehåller mest information, inte nödvändigtvis den äldsta (lägst numrerade) felrapporten.
  • Lägg till ett standardsvar som detta i den andra rapporten

När du gör en felrapport till en dubblett av en annan är det viktigt att kommunicera till rapportören att alla diskussioner om felet ska ske i den primära (master) felrapporten. Kom ihåg att NUMMER är en variabel som bör vara numret till den primära felrapporten. 

     Thank you for taking the time to report this bug and helping to make Ubuntu better. 
     This particular bug has already been reported and is a duplicate of bug NUMMER, so it is 
     being marked as such. Please look at the other bug report to see if there is any missing 
     information that you can provide, or to see if there is a workaround for the bug. 
     Additionally, any further discussion regarding the bug should occur in the other report. 
     Feel free to continue to report any other bugs you may find.
  • Klicka sen på länken "Mark as Duplicate" högst upp till vänster på felrapportsidan och skriv i numret på den primära felrapporten.

Standardsökningen i Launchpad och sökningarna ovan kommer endast att söka efter fel markerade som Open. Det kan också vara värt besväret att gå igenom listorna med fel som har markerats Invalid och Won't fix och som du kan leta efter genom att använda Advanced search. Det finns också en standardiserad feletikett för fel som troligtvis har många dubbletter - metabug.

När du markerar en felrapport som en dubblett av en annan (master) felrapport, kontrollera också om huvudfelrapporten är markerad som private. Om så är fallet kan huvudfelrapporten vara osynlig för felrapporteraren. När huvudfelrapporten verkligen är markerad som private bör du kolla varför så är fallet. Om den är private bara för att (felrapporteringsverktyget) apport som standard gör alla felrapporter till private, men core-dumpen har tagits bort och ingen av apports bifogade filer innehåller något privat, kan felrapporten bli publik. Om rapporten innehåller konfidentiell information bör felrapporten förbli private och det är då bättre att söka efter ett annat fel som kan bli markerad som huvudfel. För vägledning om statusen private för en huvudfelsrapport och markering av ett annat fel som dubblett av den, fråga i IRC-kanalen för BugSquad (#ubuntu-bugs)

[redigera] Apport kraschrapporter

En rätt stor mängd felrapporter avser programkrascher som rapporterats semiautomatiskt med Apport och blir pre-processade automatiskt av bottar i Canonicals datacenter. Dessa bottar försöker att generera en fully symbolic stacktrace och kolla efter dubbletter.

I Feisty (7.04) och tidiga Gutsy (7.10) var dessa felrapporter publika så att alla kunde se dem. Detta skapade ett säkerhetsproblem, eftersom core-dumpar och stack-traces kunde innehålla potentiellt känslig information. Kraschrapporter genererar också en hel del e-posttrafik med felrapporter som inte kan hanteras. Med automatisk dubblettkontroll blir en hel del av de rapporterade felen helt irrelevanta för felsorterarna.

I nuvarande Gutsy har dessa problem lösts genom att felrapporter från Apport registreras med flaggan private, det vill säga att bara rapportören och prenumeranter kan se den. Preprocessor-bottarna kommer att göra ubuntu-bugcontrol-teamet till prenumeranter, men inte skicka felrapporter via e-post till sändlistan.

Därför skiljer sig krasch-fel från andra fel på två olika sätt: de behöver kontrolleras för känslig data, och det kommer inte att komma ett första e-postmeddelande förrän de blir publika. Felsorteraren bör kontrollera följande saker:


  • If the crash still has a CoreDump.gz attachment, then it was not possible to automatically get a fully symbolic stack trace and check for duplicates. In this case, the bug will be tagged with apport-failed-retrace. If the stack trace looks good enough, the CoreDump.gz attachment should be removed with the (edit) link in the attachment box. If the retrace failed completely, just leave the bug alone.
  • If there is no Stacktrace.txt (retraced) attachment, then the most probable reason is that the CoreDump.gz attachment is broken. Please check with Martin Pitt (pitti in IRC, martin.pitt@ubuntu.com) about the reason, he can look into log files.
  • Check if the Stacktrace.txt (retraced) attachment has anything that looks like sensitive data passed as function arguments. Examples are passwords, things that look like bank account numbers, CSS keys, etc. If you don't find anything, you may mark the bug as public ("Visibility/security" in the top left pink box). This is not required, though, it is fine to keep the bug private throughout its lifetime.

Except for those privacy issues, crash reports should be handled like normal bugs in terms of duplicate searching/marking, upstream forwarding, etc.

[redigera] Förbättra en felrapport

En del av felsorteringsprocessen handlar om att säkerställa att felet är giltigt, väl beskrivet och innehåller tillräcklig information för att en utvecklare ska kunna börja arbeta på den.

För att anses som en komplett felrapport bör denna vanligtvis innehålla:

  • Vilken version av Ubuntu som rapportören kör
  • Vilken version av paketet som rapportören kör
  • Vilka steg/åtgärder som görs för att skapa problemet
  • Huruvida det är möjligt för rapportören att återskapa felet
  • De förväntade resultaten av dessa steg/åtgärder
  • Det faktiska resultatet av dessa steg/åtgärder

Dock innehåller inte alla felrapporter all denna information. Som felsorterare bör vi fråga efter alla dessa om de saknas. Ibland kan viss information härledas från resten av rapporten, eller vara onödig för en viss rapport. Ett bra test är att se om du kan återskapa felet själv baserat på den tillgängliga informationen. Om du är tveksam kan det vara bättre att diskutera med felrapportören innan du markerar felrapporten som incomplete (ej komplett).

Vissa klasser av fel och specifika paket kräver mer detaljerad information som konfigurationsinställningar och loggfiler. Sidan DebuggingProcedures innehåller en lista med länkar till mer detaljerad information att samla in.

Eftersom de flesta rapporter förmodligen inte kommer att vara kompletta måste du inleda en konversation med felrapportören. Be rapportören om mer information genom att göra följande:

  • Klicka på felrapportens task name, vilket vanligtvis är paketets namn, i den gula horisontella linjen.
  • Ändra fältet Status till Incomplete.
  • Fråga efter den ytterligare information som behövs i fältet Comment on this change.
  • Klicka i rutan E-mail me about changes to this bug report så att du prenumererar på felrapporten.
  • Klicka på Save changes.

Som en prenumerant på felrapporten kommer du att få e-post när felrapportören svarar.

Även om felrapporten är komplett skulle den säkert kunna må bra av lite förbättringar.

  • Är felrapportens sammanfattning nog beskrivande för felet? Detta hjälper folk att enklare hitta felrapporter.
    • exempel: "no r5xx support in radeon driver (X1300, X1400, X1600, X1800, X1900, X1950)" jämfört med
    • "update-manager" eller "Screen Saver Issues" eller "Buffer I/O Error"

[redigera] Bäst före datum för ofullständiga felrapporter

Ubuntu har inte resurser för att se till varje felrapport, vi vill fokusera våra resurser på felen vi verkligen behöver åtgärda. Att ha tiotusentals felrapporter i systemet som vi inte kan eller har möjlighet att fixa är inte konstruktivt, det gör åtgärdandet vi kan göra mindre effektivt. Vi fokuserar på fel som introducerats i Ubuntus paketeringsprocess, eller specifika fel för Ubuntu-versionerna av paket och fel som skapar stora problem för många användare. Vi fokuserar också vår uppmärksamhet på fel som är väl definierade och kompletta, eftersom dessa är de fel som utvecklare har störst chans att åtgärda inom rimlig tid.

Många fel är också åtgärdade från en release till nästa eftersom de åtgärdas i nya versioner uppströms (från moderpaketet) som blir paketerade för den nya Ubuntu-releasen. Det kan vara svårt att få uppmärksamhet från felrapportören om de har uppgraderat till en ny version, eller åt andra hållet, det är viktigt att försöka avgöra om en icke komplett rapporterat fel har åtgärdats i en ny version.

Därför kommer felrapporter som markeras som Incomplete att slutligen försvinna från de primära rapportlistorna för utvecklare.

Om en felrapport inte är helt definierad, markera den som Incomplete och fråga om den fortfarande är giltig. Om en ny version av Ubuntu har släppts är det också nödvändigt att fråga om felet fortfarande uppkommer i den nya releasen och i så fall markera felrapporten som Incomplete. Om inte felrapportören återställer felrapportens status kommer dess tid att så småningom löpa ut.

[redigera] Bekräfta felrapporter

När du har en komplett rapport och det är nog med information för att avlusa programmet, kan du bekräfta rapporten. Hur vet du då att det är nog med information? Här är några exempelkriteria som bör uppfyllas. Det är ingen inbördes ordning och du kan göra dem i vilken ordning du vill, ANY of which is sufficient:

  • Finns det en patch som gör anspråk på att åtgärda felet?
  • Finns det tillräckligt med loggfiler och kraschdumpar, som skisseras i DebuggingProcedures?
  • Kan du själv återskapa felet?
  • Har någon annan distribution en komplett och bekräftad felrapport?
  • Har upphovsmannen uppströms en komplett och bekräftad felrapport?

Om NÅGON av dessa villkor är uppfyllda kan du bekräfta rapporten. För att göra detta:

  • sätter du Status-fältet till Confirmed.
  • sätter du värdet Importance till ett värde som överensstämmer med Importance-skalan
  • ändrar du Assigned to-fältet till Nobody och
  • klickar på Save changes.

Oroa dig inte om en felrapport som du bekräftat, som inte kan skickas uppströms fortsätter att vara confirmed en lång tid framöver. Ubuntu har många, många felrapporter och utvecklarna kommer att kolla på bekräftade fel först.

[redigera] Status och Importance

Om det förekommer tveksamheter bör paketansvarig (eller den som arbetar med felet) ändra Status och Importance. Det återspeglar ofta statusen på arbetet eller visar hur felet passar in i hennes/hans arbetstid.

Se sidorna Importance och Status

[redigera] Vidarebefordra uppströms

ATT GÖRA!

[redigera] Resurser för felrapporter uppströms

  • The Upstream Report - Bug linkage percentages for the top 50 projects in Ubuntu, sorted by open bugs. Please note that this report is still in Beta. Instructions for using the report.
  • Bugs that need forwarding to the Upstream bugtrackers.
  • Unlinked upstream bugs - Sometimes people add a link to an upstream bug tracker in the comments of a bug but don't bother creating an upstream task. This is a list of possible targets that can be linked. (Lots of low hanging fruit in this list, but also a bunch of dupes and ones inappropriate to be linked.)
  • How to set a bug watch
  • Why Upstream? - Thoughts from freedesktop.org on why sending things upstream is a good idea.

[redigera] Felhanteringssystem uppströms

Instruktioner för hur du registrerar fel i särskilda felhanteringssystem uppströms (ligger på https://wiki.ubuntu.com/Bugs/Upstream)


[redigera] Markera en felrapport som behöver vidarebefordras

Om du hittar en felrapport som behöver vidarebefordras, är det bäst att vidarebefordra den omedelbart. Men om så är fallet att du har ont om tid, kan du ändå markera felrapporten som needs forwarding. För att göra detta:

  • Öppna en "upstream task" (du klickar på "Also affects project"), men tilldela ingen "bug watch" (efter sidan med "Record as affecting another project" på sidan med "Confirm project". du klickar istället på "I just want to register that it is upstream right now; I don't have any way to link it."). Var uppmärksam på ordalydelsen (det finns ett fel registrerad mot LP-felrapporten #353097)
  • Detta kommer att markera felrapporten som "needs forwarding"
  • Du kan söka efter dessa felrapporter i "Advanced Search" genom att välja rutan "Show only bugs that need to be forwarded to an upstream bugtracker".

[redigera] Ogiltigförklara

Ibland måste du ogiltigförklara en felrapport. Det kan bero på att problemet inte kan återskapas, eller att programmet är utformat för att uppföra sig på ett visst sätt.

Det kommer också att finnas en del felrapportörer som aldrig återkommer till dig och där rapporterna inte innehåller tillräckligt med information för att felen skall kunna arbetas på. Dessa kommer också att behöva markeras som Invalid.

Det bästa sättet att göra detta är att vänligt avsluta rapporten och tacka användaren för att han eller hon skickade in den. Det finns ett antal användbara standardsvar för dessa fall.

Det finns ingen anledning till att avvisa felrapporter som redan är markerade som dubblett av en annan felrapport. Att göra så resulterar i en massa onödig e-posttrafik eftersom alla felprenumeranter till dubbletten och huvudfelet kommer att få e-post om att statusen till felrapporten ändrats från något till Invalid.

I händelse av att felrapporten haft statusen Incomplete i mer än fyra veckor, vilket innebär att den inte fått någon återkoppling från en kompletteringsförfrågan, sänd i så fall en vänlig påminnelse med något liknande:

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

Om rapportören fortfarande inte har svarat efter ytterligare två veckor och det inte finns någon möjlighet att arbeta med felrapporten, bör felrapportens status ändras till Invalid med en kommentar liknande:

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[redigera] Funktionsförfrågningar

Om rapporten egentligen är en förfrågan om en ny funktion, bör felrapportens Importance bli satt till Wishlist av någon i gruppen Bug Control. Klistra in felrapportens nummer i #ubuntu-bugs och tala om att du tycker att felrapporten bör omprioriteras till wishlist. Någon kommer att upptäcka och fastställa den åt dig, även om de inte nödvändigtvis gör det omedelbart.

Under tiden kan du lämna den här standardkommentaren:

Thank you for taking the time to make Ubuntu better. Since what you submitted is a Feature Request to improve Ubuntu, you are invited to post your idea in Ubuntu Brainstorm at http://brainstorm.ubuntu.com/ where it can be discussed, voted by the community and reviewed by developers. Thanks for taking the time to share your opinion!

[redigera] Regressioner

Det är särskilt viktigt att vi fångar felrapporter om regressioner och får utvecklarna att uppmärksamma dem. Detta inkluderar regressionsanalyser i nuvarande stabila utgåvor, i uppdateringar, i den föreslagna kön eller potentiella regressioner i nästa utgåva. Dessa bör vara märkta med följande taggar: regression-release, regression-update, regression-proposed and regression-potential.

Så snart den har taggats, kommer felrapporten visas på regression tracking page och kommer därifrån flyttas upp till utvecklingsteamen. Se QATeam/RegressionTracking för ytterligare information.

[redigera] Speciella typer av fel

Alla fel är inte likadana. De flesta fel är kod- eller paketeringsdefekter, men vissa grupper använder även felrapporterna för andra saker. Du bör vara extra försiktig med dessa felrapporter så att du inte stör gruppernas arbetsprocesser. Dessa felklasser har speciella regler och betydelser för olika statusmeddelanden. De kan till och med ha olika betydelse beroende på var Ubuntu är i sin utgivningscykel. Om inte en sorterare är bekant med de särskilda processerna i fråga, kan justeringar i dessa felrapporter orsaka problem.

[redigera] Fel i utvecklingsprocessen

Du bör vanligtvis inte ändra felrapporter av den här typen om du inte arbetar med en utvecklare/paketerare.

För paket i Universe/Multiverse, se sidan [Sponsors Queue] för ytterligare information.

[redigera] Fel som behöver paketering

Du kan ibland hitta en felrapport med en ämnesrad som liknar : [needs-packaging] <paket>. Dessa felrapporter används för att spåra program som efterfrågas att bli ett Ubuntu-paket. För dessa felrapporter kan du:

  • kontrollera om programvaran redan finns paketerad i Ubuntu (se http://packages.ubuntu.com, eller kör rmadison <paket>): om den redan finns i arkiven, markera felrapporten som Invalid och lägg till en kommentar varför;
  • om den inte finns i Ubuntu, kolla i Debian (se http://packages.debian.org, eller kör rmadison -u debian <paket>). Om den finns i Debian, markera felrapporten som Invalid, och lägg till en kommentar liknande:

Packages for this software appear to exist in Debian already. Ubuntu has semi-automatic tools to sync new packages from Debian so it will most likely appear in the next Ubuntu release.

  • sätt statusen till Confirmed om paketet inte finns vare sig i Ubuntu eller Debian. Sätt också importance till Wishlist (om det är möjligt) och lägg till etiketten needs-packaging om den saknas.
    • sätt statusen till Triaged om uppströms licensinformation och URL finns tillgängliga.
  • göra ytterligare saker som att kolla Work-Needing- och Prospective Packages-sidan hos Debian. Om du hittar en felrapport för begäran om samma program i Debians felhanteringssystem, lägg i så fall till en upstream bug watch för den.
  • se Example Request för önskad information.

Observera: alla paketnamn är inte intuitiva! Använd också paketbeskrivningarna som hjälp för att guida dig.

  • Om du är osäker på om felet som du tittar på platsar i någon av dessa kategorier, fråga då gärna på #ubuntu-bugs eller #ubuntu-motu på Freenode.

[redigera] Säkerhetsfel

SecurityTeam använder en liknande men något annorlunda process för att sortera fel. Om du tror att detta kan vara ett säkerhetsfel eller håller på att sortera en felrapport som flaggats som security, läs igenom SecurityTeam/BugTriage innan du fortsätter.

[redigera] Att titta igenom dina felrapporter

Du kanske vill kolla igenom en lista på de felrapport du arbetar på, för att se om någon har svarat.

Ett bra sätt att få en lista över dessa felrapporter är att kolla på dina relaterade felrapporter. Dessa kan hittas på din Bugs-sida på Launchpad:

Du kan se dina felrapportsprenumerationer på http://bugs.launchpad.net/people/+me/+subscribedbugs, eller felrapporterna du kommenterat på http://bugs.launchpad.net/people/+me/+commentedbugs. Länkar till båda dessa finns på din Bugs-sida.

Du bör gå igenom dina felrapporter ganska ofta, kanske en gång varje vecka, för att säkerställa att du inte har missat några nya kommentarer eller ändringar. Detta inkluderar fel som du rapporterat uppströms. Om det finns någon viktig kommentar från en felrapport uppströms, bör du lägga till den i Ubuntus felrapport.

Hämtad från "http://www.ubuntu-se.org/wiki/HowtoTriage"
Personliga verktyg