De tusinde fejls software

Vi har lige rundet Trac-ticket nummer 1000 i Varnish.

Den første ticket blev åbnet for fem år siden, så i runde tal taler vi en ticket hver anden dag.

Jeg har valgt en næsten ben-hård politik om at tickets kun er til fejl der kan gøres noget ved. Hvis nogen åbner et ticket der er en feature-request, vag ide, eller ikke, trods henvendelse, leverer de nødvendige informationer, bliver sagen bare lukket.

Ideer og feature-requests samler vi naturligvis op i nogle Wiki sider til formålet.

Nu kan man ikke umiddelbart sammenligne Varnish med FreeBSD, men det er ingen hemmelighed at det er FreeBSD's GNATS database der er årsagen til min noget hårdhændede politik i Varnish: Hvis man ikke konstant er over dem, bliver bug-trackere til jungler der er umulige at rydde op i. Pt er der f.eks næsten 4000 PR's i FreeBSDs GNATS, den ældste er fra februar 2003...

Der er ikke noget mere nedtrykkende, end at kigge på en gammel fejlrapport for en version af softwaren der ikke kører nogen steder mere, afsendt fra en person der har skiftet job 4 gange i et land der nu hedder noget andet.

Derfor skal tickets ikke have lov til at ligge og gære i bunden af en eller anden database: Enten skal der handles, eller også skal de lukkes fordi der ikke kan handles.

Måden vi holder listen nede på, er meget simpel:

Hver mandag ved frokosttid holder vi et IRC-møde, hvor vi kigger nye tickets igennem og aftaler hvem/hvad/hvordan de skal håndteres. Derefter kigger vi på de gamle tickets, enten i "senest rørt" eller "længst urørt" rækkefølge for følge op og får ryddet ud.

Mit personlige mål er at vi ikke har over 30 åbne tickets og pt. siger badevægten 37, så det er ikke helt tosset, taget i betragtning at vi lige er kommet igennem et major (3.0.0) og et minor (3.0.1) release.

Hvis 3.0.1 ser ud til at holde vand, er der nogle lidt større problemer der skal på operationsbordet, nogle af dem repræsenteret ved flere tickets.

De tickets vi har sværest ved at gøre noget ved, er dem der i virkeligheden stiller store spørgsmål. Vores pt. mest mugne ticket handler om et Python-API til Varnish statistisk & logfiler. Men skal vi i det hele taget shippe et sådant API i Varnish, eller burde det retteligen leve ude i Python-land ? Nu har vi endelig taget os sammen og besluttet at det hører ikke til i Varnish, det hører til i Python verdenen, så efter lidt fodarbejde kan vi snart lukke den ticket også.

Ahh, pokkes, #1001 er også lige indløbet...

phk

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Troels Arvin

Hvis man har en politik om, at alle commit-beskeder skal have en reference til en ticket, kan det være en fordel af være mere liberal mht. tickets: Dels kan det være en fordel at have tickets af typen "Evergreen", der fx. kan handle om generelle små-forberinger i kodekommentarer og som ikke nødvendigvis nogensinde lukkes. Eller RFE (request for enhancement)-tickets, som i sagens natur ikke vedrører fejl.

En politik om at der skal være ticket-reference i alle commit-beskeder kan i første omgang virke ret anal, men jeg blev faktisk glad for den, da jeg engang arbejdede et sted, hvor vi havde politikken. Og den betød også, at man ofte kunne spare tid ved ikke at skulle forfatte lange commit-beskeder (hvis folk vil have det fulde billede, kunne de bare følge ticket-referencen).

I et godt ticket system (eller evt. blot en veletableret navngivningskonvention for evergreens/RFEs) bør man kunne kategorisere den slags tickets på en måde, så de ikke stresser eller fjerner synligheden af mere konkrete (fejl)tickets.

  • 0
  • 0
#6 Martin Bøgelund

Så har man i min verden ikke helt forstået forskellen på et bug-tracking system og et time/sags-system...

Jeg skal ikke kunne afvise at der er mangler i min forståelse på dette område, men vi har et lignende setup a la det Troels beskriver. Den samlende konceptuelle ide her er ITIL[1]. Og der er mange der anerkender at koblingen mellem "commits" (i en lidt bredere fortolkning) og dokumentation af diverse art, er et plus når man skal rode rundt i ændringer i systemer, herunder enhancement requests.

Da jeg læste dit indlæg første gang, tænkte jeg at "Det slipper de projekter kun afsted med fordi det er open source, og udvikling finder sted på udviklernes præmisser."

I en privat organisation med interne eller eksterne tickets, vil der være en del politik, organisationshierarki, og "kunden har altid ret", som der skal tages hensyn til - en IT-funktion har ikke samme mulighed for at melde ud at det er "my way or the highway", som open source projekter nok har.

[1] http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

  • 0
  • 0
#7 Poul-Henning Kamp Blogger

[...]der er mange der anerkender at koblingen mellem "commits" (i en lidt bredere fortolkning) og dokumentation af diverse art, [...]

Den del er vi ikke uenige om, det er kun hvor koblingen sker til. I bruger bug-tickets, sandsynligvis af nød, koblingen burde være til et time-sags system således at også tid og aktiviter der ikke ender i et commit bliver henført det rette sag.

  • 1
  • 0
#8 Martin Bøgelund

Den del er vi ikke uenige om, det er kun hvor koblingen sker til. I bruger bug-tickets, sandsynligvis af nød, koblingen burde være til et time-sags system således at også tid og aktiviter der ikke ender i et commit bliver henført det rette sag.

Jeg tror jeg forstår lidt bedre nu - du vil sikkert kalde vores system for et time-sags system, og ikke en bug-tracker. Bug-tracking er så bare én type sag i vores system, eller en type af aktivitet indeni en sag.

Det der undrede mig var dit ønske om at holde sagstyper adskilt, rent systemmæssigt - forbedringsforslag i wiki'en, og bugs i bug-trackeren.

Ville det give mening at have time-sags styring i FreeBSD og Varnish? Forbedringer kan kaste bugs af sig, og bugs forbedringsforslag. Koblingen vil så kunne laves indenfor samme system.

  • 0
  • 0
#9 Robert Larsen

Nu har vi endelig taget os sammen og besluttet at det hører ikke til i Varnish, det hører til i Python verdenen

Det lyder meget logisk. Ellers får I nok også snart et featurerequest til Perl/Ruby/JavaScript

  • 2
  • 0
#10 Poul-Henning Kamp Blogger

Det der undrede mig var dit ønske om at holde sagstyper adskilt, rent systemmæssigt - forbedringsforslag i wiki'en, og bugs i bug-trackeren.

I et FOSS projekt har du ikke nogen økonomi der skiller skæg fra snot, du er nødt til at gøre det på anden vis. Hvis du blander ønskelisten med fejlrapporterne drukner fejlene og bliver ikke rettet.

Fejl bør der, i min verden handles på ASAP, mens forbedringer, ideer og ønsker bør tænkes grundigt igennem og analyseres inden man giver sig i kast med dem.

  • 7
  • 0
Log ind eller Opret konto for at kommentere