Tag: triage

5 a day – Ubuntu bug triaging fortsat

Som opfølgning på min tidligere blog post om bug arbejde i Ubuntu følger her lidt mere uddybende info. Både flere (og lidt mere avancerede) bug opgaver og nogle flere ressourcer, der forhåbentligt kan gøre bug arbejdet lettere og sjovere.

Duplikats
Hvis flere forskellige bugs egentlig handler om det samme problem er der tale om duplikater, og det er praktisk at samle alt information et sted. Oftest foregår det sådan at den ældste bug forbliver åben, mens de andre bliver markerede som duplikater. Til at starte med kan det godt være svært at vide om en bug man sidder med er en duplikat, men hvis man har brugt lidt tid på bug arbejdet vil man nogle gange have en følelse af at have set den beskrevne problemstilling før – så er der nok tale om en duplikat.

duplicat

Markering som duplikat foregår i menuen ude til højre.

Link upstream
Meget få af programmerne i Ubuntu er skrevet direkte til Ubuntu. Så hvis der f.eks. er en fejl i Firefox i Ubuntu, så er den samme fejl måske også tilstede i den originale Firefox kildekode og Firefox pakken i Fedora. I disse tilfælde er det praktisk at få en bug registreret upstream og hvis den allerede er registreret så få de to bugs som beskriver det samme problem kædet sammen.
Dette foregår ved at klikke Also affects project eller Also affects distribution.

Bug squad og Bug Control
Der findes rigtig meget information på Bugs wikisiden. Her kan du finde kontaktinfo til Bug Squad, der er både en mail liste, irc kanal og Launchpad gruppe hvor man kan få hjælp og svar på spørgsmål angående bug arbejde. Alle kan være medlem af Bug Squad. Du kan også ansøge om en mentor, som altså er et erfarent medlem af Bug Squad som kan hjælpe med at sætte dig ind i en fornuftig arbejdsgang.

Hvis du føler at du har godt styr på bug arbejdet kan det være at det skulle ansøge om medlemskab af Ubuntu Bug Control.

5 a day
Hvis du har arbejdet lidt med at finde de rette pakker til bugs, der mangler en tilknyttet pakke (eller har fået tilknyttet en forkert pakke) vil du hurtigt finde ud af at det bliver lettere med tiden. Så hvorfor ikke afsætte et par minutter hver dag til lige at gøre noget godt for 5 forskellige bugs?
Dette er filosofien bag 5 a day. Hvis vi alle gør lidt hver dag burde det være muligt at holdet styr på den meget store mængde fejlrapporter som bliver indberettet mod Ubuntu distributionen.
Det handler selvfølgelig bare om at komme i gang! Hvis man er lidt glad for stats, eller måske har det lidt godt med et konkurrence aspekt, så kan man blive medlem af 5-a-day-participants/ gruppen på Launchpad. Når man har tilmeldt sig Launchpad gruppen sker registreringen om man har nået sine fem daglige automatisk. Man behøver ikke at foretage sig andet.
… men husk nu at det i sidste ende handler om at gøre Ubuntu bedre. Hvis du kun når tre bugs en dag har du stadig hjulpet – og du kan sagtens fortsætte til bug nr. 6 og 7 efter du har nået den daglige 5.

Det er nu muligt at følge med her fra dag til dag for at se om man selv har nået sine fem om dagen. Samtidig kan man, hvis man kan holde dampen oppe over flere uger, komme på nogle af de fine lister over dem der har holdt ud længst tid i træk.

Det er vigtigt at bemærke at 5 a day er blevet udtænkt for at gøre det lidt sjovere at triage bugs. Det er ikke ideen at man skal gøre noget ved bugs som egentligt ikke var behøvet, bare for at kunne tælle det med i en af sine fem om dagen. På sammen måde som der ingen ide er i at lave unødigt bug-arbejde bare for at få karma.

Bug triaging

Der er mange måder at hjælpe med udviklingen af Ubuntu. Man kan hjælpe med support, ved at hjælpe andre brugere med deres problemer, man kan hjælpe med oversættelser, man kan advokere for udbredelsen af Ubuntu, man kan arbejde med dessign og brugervenlighed, man kan arbejde med fejlrapporter (bugs) …og sikkert en masse andet, som jeg glemmer.

Der skal kun en lille smule teknisk snilde og rimelige engelskundskaber til, for at kunne hjælpe med bug arbejdet. Det er ikke et arbejdsområde, som er forbeholdt udviklere.

Der er få fejlrapporter, som er direkte klar til at blive arbejdet på af udviklerne. Rigtig mange bugs indeholder ikke nok information eller er rapporteret mod forkerte pakker. Her kan alle hjælpe med. Man skal bare have oprettet sig som bruger på Launchpad og så ellers gå i gang.

Hvis en bug rapport kun indeholder information som “Firefox crasher” så er det meget svært for en udvikler at gøre noget ved det. I situationer hvor en rapport indeholder for lidt information ændres status til Incomplete og man skriver et svar hvor man udbeder mere information.
Der findes standard svar, så man skal ikke engang bruge lang tid på formuleringen.

Mange bugs bliver rapporteret mod Ubuntu generelt og ikke mod den pakke som indeholder det program der er en fejl i. Nogle gange er det oplagt, når man læser bug beskrivelsen, hvilken pakke den egentlig bør rapporteres imod. Fejl i programmer skal som hovedregel rapporteres mod den pakke som programmet kommer fra. Andre gange er det knapt så indlysende. Heldigvis er der hjælp at hente her. Hardware fejl er ofte kerne relaterede, og skal rapporteres mod linux pakken. Fejl under installationen hører ofte til ubiquity pakken. Grafik fejl hører ofte til Xorg pakken.
I bunden af wiki siden er der også info om hvordan man finder ud af hvilken pakke et program eller en fil stammer fra.

Hvis vi ser på en generel bug vil vi ovenover beskrivelsen af fejlen blive mødt af følgende på Launchpad:

1

Hvis vi vil ændre status er det blot at klikke under status, hvor der oftest ved nye bugs vil stå New.

1-status

Her er mange muligheder, men hvis man ikke er udvikler er de mest interessante for os Incomplete og Invalid. Incomplete bruges hvis der ikke er nok info i rapporten til at begynde at løse problemet og skal ledsages af en besked som beskriver hvordan den ønskede info skaffes. Invalid bruges hvis bug rapporten ikke er relevant. F.eks. hvis en fejl rapporteret mod installeren viser sig at være opstået pga. en fejlbrændt cd.
2

Hvis bug’en er rapporteret mod den forkerte pakke, eller hvis den (som det ofte sker) er rapporteret mod Ubuntu distributionen og det er klart hvad den rette pakke er (evt. med hjælp fra denne liste), så ændres dette ved at klikke på pilen til venstre som markeret nedenfor.

1-affects
Her kan man vælge den rette pakke, som omtalt ovenfor. F.eks. pakken linux, som ofte er den rette til bl.a. hardware problemer.
3-package

Endelig kan man, hvis man er nysgerrig for hvad der kommer til at ske med bug’en herfra bede om at blive underettet pr. email når der sker ændringer. Specielt hvis man er ny til bug arbejdet kan det være en god ide – både for at få en forståelse for hvornår en bug kan betragtes som færdig, men også for at finde ud af om man har fundet den rette pakke.

5-email

Så for at opsummere:

Her er en liste over bugs rapporteret mod Ubuntu og som mangler at blive tilknyttet til en pakke. Et rigtigt godt sted at starte sit bug arbejde. Der er flere lette opgaver at finde her.

Her er info med hjælp til at finde den rette pakke.

Her er en liste med standardsvar, som bl.a. kan anvendes når man vil bede den oprindelige bugrapporter om mere info.

God fornøjelse!

Late Global Jam in Copenhagen

Better late than never… due to some scheduling problems we didn’t manage to run a Global Jam last weekend, as the rest of the Ubuntu community did.

However, luckily we managed to run a jam yesterday, Saturday 10. If it could be called a part of the Global Jam, or if it was just our Local Jam is really just a matter of words. The five of us ended up working primarily on bug triaging. However we also had a quick look at the features of Empathy (the new default instant messaging client in Karmic Koala), and the Ubuntudanmark Podcast guys did a quick segment for their next podcast.

All in all I think the jam was a success, and I think we are ready for similar events in the future.