Toimiva bugien käsittely vaatii eritasoisia ihmisiä. Tarvitaan niitä bugiraportteja, mutta tarvitaan myös niitä ihmisiä jotka osaavat jalostaa usein "raa'asta" bugiraportista sellaisen raportin, että se sisältää tarvittavat tiedot. Sitten tarvitaan vielä ihminen joka asian osaa korjata, joka ei useinkaan välttämättä ole sama henkilö joka on nimellisesti paketin ylläpitäjä Ubuntussa. Korjaus pitää osata toimittaa paketin ylläpitäjälle/kehittäjälle mahdollisimman helpolla tavalla, ja sitten vielä paketin ylläpitäjän pitää ehtiä arvioimaan korjauksen luotettavuus, ottamaan se vastaan ja sisällyttää Ubuntuun.
Ubuntun bugien korjaaminen on yhteisötoimintaa siinä missä sekin, tuleeko täällä foorumeilla kysymyksiin vastauksia. Ja samoja lainalaisuuksia on, paitsi vielä isompina, eli yhtä aktiivista kehittäjää kohden voi olla 1000 bugiraporttia. Jos bugiraportti on luokkaa "ei toimi tällä koneella xyz", niin sille ei kehittäjä voi juuri tehdä mitään ellei ole sama kone käytettävissä jolla ongelman voisi toistaa. Tällöinkin ongelma voi johtua jostakin asiasta, jonka takia ongelmaa ei voi toistaa eikä siten tutkia. Jos syykin on löydetty, yhden bugin korjauksen löytäminen ja testaaminen voi viedä 15 minuutista päiväkausiin.
Bugiraporteissa olevat lisätietokyselyt tulevat nekin yleensä yhteisön jäseniltä, jotka harrastavat tätä kyselyä ja "Triaged":ksi merkitsemistä. Tämä auttaa kehittäjiä näkemään, että "ahaa, tuon nimisessä bugissa _saattaa_ ainakin olla tarpeeksi tietoja varsinaisen ongelman selvittämiseksi". Myös yhtä bugitriagoijaa kohden lienee helposti tuhat bugia, mutta on huomattavasti helpompaa kysellä lisätietoja suht rutiininomaisesti kuin lähteä varsinaisesti selvittämään ongelmaa.
Jos oikeasti haluaa saada jonkin tietyn, lähinnä omaa kokoonpanoa koskevan ongelman korjatuksi, on paras tapa keskittyä siihen miten ongelman korjaamisen tekee mahdollisimman helpoksi esim. paketin ylläpitäjälle. Esimeriksi jokin laiteongelma tietyllä komponentilla, ja havaittuna kiertokeinona esim. kernelin moduulille parametri:
1. Tulee selvittää mihin esimerkiksi laitekomponentin PCI-ID:tä vastaava poikkeussääntö tulee lisätä.
2. Tulee ottaa esim. hal:n/minkälie lähdekoodi (apt-get source hal), tehdä tarvittavat lisäykset ja tehdä bugiraporttiin liitettäväksi testatusti toimiva patchi (esim. diff -urN vanha-versio-hakemisto uusi-paranneltu-versio-hakemisto > mun_patchi.patch)
Tässä on se hankalin osuus tietysti tehty, eli on ylipäänsä löydetty ongelmaan korjaus. Mutta patch ei vielä ole optimaalinen tapa tarjota korjausta, vaan:
3. apt-get source yleensä kertoo, jos paketilla on versionhallinta tietyssä Bazaar-versionhallinnassa. Tulee siis ottaa bzr-työkalulla kyseinen kehitysversio vaikka hal:sta ja tarkistaa toimiiko patch myös siellä.
4. Lisäksi tulee luoda omalle Launchpad-tunnukselle Bazaar-haara (code.launchpad.net / Register Branch) kyseisestä paketista, johon lykkää korjaukset.
5. Tämän jälkeen vielä Merge / Review Request emohaaraan, ja bugiraporttiin viittaus korjauksen sisältävään bzr-haaraan.
(6. Korjauksen mentyä sisään korjauksen lähettäminen varsinaiselle hal-projektille, tai keskustelu Ubuntu-ylläpitäjän kanssa siitä miten korjaus toimitetaan eteenpäin)
Jos tällaiseen tilanteeseen pääsee, että korjattu versio löytyy bzr-versionhallinnasta, niin ongelman korjaus on tehty mahdollisimman helposti käyttöönotettavaksi. Tällainenkin bugiraportti voi kuitenkin mennä niiden tuhansien muiden kommenttien myötä ohitse, joten jos pariin viikkoon ei tapahdu mitään, kannattaa esim. pingata kehittäjää sähköpostitse tai IRCissä korjauksen mukaan ottamisesta.
Tämän pointti oli lähinnä yrittää muistuttaa, että ei edes kannata olettaa (tai pettyä) että tietty bugiraportti pelkällä nopealla raportoinnilla tulee korjatuksi, ellei ongelman teknisesti oikeanlainen korjaus ole ilmoitettu samassa raportissa. Ubuntun (kymmenet?) miljoonat käyttäjät ovat luoneet suhteellisen lyhyessä ajassa yli 300 tuhatta bugiraporttia, joista suurimmassa osassa ns. signaali-kohinasuhde ei ole mikään paras mahdollinen. Tällaisen määrän hallitseminen on yhtä lailla tai enemmän aktiivisten yhteisöjäsenten kuin varsinaisesti palkattujen kehittäjien (n. 100 max.) varassa, etenkin koska moni bugeista on kehittäjän kannalta sen verran epämääräinen ettei sitä kertakaikkiaan pysty tutkimaan esim. ilman juuri samaa laitekokoonpanoa.
Minä tahansa hetkenä on myös tiedossa satoja useaa käyttäjää koskevia bugeja, joita on mielekkäämpää tutkia kun yleensä myös tietoa ongelman aiheuttajasta on enemmän. Ja samaan aikaan pitäisi tehdä myös muuta kuin bugien korjausta, esimerkiksi kehittää seuraavaa Ubuntun julkaisua.
Aihe: Yleistä keskustelua Launchpad bugiraportoinnista (Luettu 15235 kertaa)
