Löysin esimerkiksi bugtrackeristä bugin https://bugzilla.gnome.org/show_bug.cgi?id=508846 . Se on määritelty tärkeysluokassa urgentiksi, mutta silti sen korjaaminen on kestänyt vuosia. Onko IT-ala sellaista, että kiireellisetkin asiat voivat kestää useita vuosia?
Miksi avoimen koodin korjaus on välillä hidasta?
uteliasI
11
2025
Vastaukset
Lue tarkemmin.
Severity: enhancement
Ei siis varsinainen vika vaan parannus.
Ja sen lisäksi kommentti 9 kertoo jo patchista, eli homma on jo hoidettu melkein 7v sitten.
Keksit mielivaltaisen ongelman joka liittyisi muka jotenkin avoimeen koodiin ja lähempi tarkastelu näyttää että ongelmaa ei edes ole.- uteliasl
Okei. Mut miks tommoset säilyvät bugtrackerissä, jos vika on jo korjattu?
uteliasl kirjoitti:
Okei. Mut miks tommoset säilyvät bugtrackerissä, jos vika on jo korjattu?
Siellä on varmaan 10000 bugiraporttia joten kyllähän tuossa määrässä alkaa olla ylläpitämistä.
Ehkä niillä ollut parempaakin tekemistä kuin siivota jotain 7v vanhoja juttuja pois.
Voithan sinä tietysti itse käydä jokaisen avoinna olevan bugin sieltä läpi, tarkistaa että onko se korjattu (ja että ei ole uudestaan pompannut esiin), ilmoittaa kehittäjille mitkä pitäisi sulkea pois ja ilmoittaa niihin raportteihin versiotiedot yms. kuntoon.- koodari
M-Kar kirjoitti:
Siellä on varmaan 10000 bugiraporttia joten kyllähän tuossa määrässä alkaa olla ylläpitämistä.
Ehkä niillä ollut parempaakin tekemistä kuin siivota jotain 7v vanhoja juttuja pois.
Voithan sinä tietysti itse käydä jokaisen avoinna olevan bugin sieltä läpi, tarkistaa että onko se korjattu (ja että ei ole uudestaan pompannut esiin), ilmoittaa kehittäjille mitkä pitäisi sulkea pois ja ilmoittaa niihin raportteihin versiotiedot yms. kuntoon.Tuskinpa pomppaa uudelleen esiin. Eiköhän joka bugista tehdä aina testitapaus, jotka ajetaan aina kun patchit arvioidaan. Tai ainakin ite koodaan siten, että jokaisesta tekemästäni virheestä teen testin.
koodari kirjoitti:
Tuskinpa pomppaa uudelleen esiin. Eiköhän joka bugista tehdä aina testitapaus, jotka ajetaan aina kun patchit arvioidaan. Tai ainakin ite koodaan siten, että jokaisesta tekemästäni virheestä teen testin.
Tuskin, mutta aina kun puhutaan isosta määrästä mitä tahansa niin aina käy jotain jännää.
Ei tietokoneen prosessoritkaan yleensä hajoa vaan siellä on monta muuta osaa mitkä alkaa yleensä piiputtaa aikaisemmin mutta kyllä aina joskus löytyy viallinen prosessori.
- hmh,
Pääasiassa siksi, että useiden avoimen koodin ohjelmien kehityksen eteneminen perustuu vapaaehtoisuuteen.
Tai sitten esim tilanne, jos yritykset osallisuvat kehitykseen, he kehittävät sitä heille oleellista osa-aluetta pääasiallisesti. - ruususen_temppeli
Ei kannata jättää open-source koodausta kaupallisten tahojen vastuulle pelkästään. Voi näet olla, että projektin loputtua koodin ylläpitoon ei enää saa käyttää aikaa.. on sitten kehittäjästä kiinni, tuleeko vapaa-ajalla tehtyä korjauksia, vaiko sitten ei. Veikkaan jälkimmäistä, jos on jo tehnyt 8h päivän koodia..
Siis koodia ylläpidetään sen aikaa mitä on luvattukin. Kyllä ylläpitoasiat ihan normaalisti käydään läpi kun otetaan ohjelmistoa käyttöön.
- hmhmhm
Useimmissa pienemmissä projekteissa se johtuu yksinkertaisesti siitä, että projektin eteneminen perustuu tekijöiden vapaaehtoisuuteen. Silloin kukanenkin tekee pääasiassa sitä, mikä sattuu kulloinkin kiinnostamaan.
Nopeampi ja järjestelmällisempi kehitystahti tarkoittaa usein sitä, että pitää palkata joku koodaamaan.
Isommissa projekteissa näin tietysti tehdäänkin. Toisinaan yritykset osallistuvat kehitykseen, kehittäen jotakin osaa omaan tarpeeseensa, silloin siitä usein hyötyvät kaikki kun he korjaavat bugeja vähemmäksi.- 7or7
Usein yritysten sekaantuminen kehitykseen aiheuttaa myös ongelmia. Vrt. antaisitko libre-officen kehitystyön microsoftille? Kehittävä organisaatio pitää aina pitää varpaillaan koodin omistajuuden suhteen - se pitää voida menettää koska tahansa, koska kehitys voi olla myöskin takaperoista. Monille yrityksille on myös hankaluuksia ymmärtää se tosiasia, että koodi kehittyy itse asiassa aika vapaaseen suuntaan - kehityksen suunnan määrääminen voi olla aika tuhoon tuomittua!
"Vrt. antaisitko libre-officen kehitystyön microsoftille?"
Saa sekin siihen muutosta lähettää. Toki projektin ylläpitäjät voivat katsoa, että jos muutos on kelvoton niin sitä ei oteta.
"kehityksen suunnan määrääminen voi olla aika tuhoon tuomittua!"
Se on. Regulointi ja lainsäädäntö sitten on se mikä toimii. Sillä ei voi määrätä kehityksen suuntaa mutta voidaan asettaa vaatimuksia.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Erään T miehen viimeinen aloitus tänne
Moi Olen kirjoittanut täällä säännöllisesti yli 5 vuotta. Kaivannut kuten kuuluukiin, mutta myös unohdellut ja selvitel353805Sanna vaihteeksi Australian "60 minuuttia" ohjelmassa
Kansanvälinen superstaramme esiintyi tällä kertaa toisella puolen maapalloa esitettävässä ohjelmassa. Kiinnostus on kova1362517Yritykset verolle ja yritystuet 10 mrd. eur/v pois
Kiristämistapauksissa yrityksille sanotaan hei hei. Suomi ei tarvitse yhteiskunnan rahoilla "yrittämistä". Yhteiskunta v612063Yritän saada sinut pois mielestäni ja ajatuksistani nainen
Turhaan. Mitä enemmän yritän, sitä enemmän haluan sinut ja sinua. Miten voitkaan olla niin ihana ja tuntua niin hyvältä.781626Sanna Antikainen (ps) : Vornasen pyssy suututti demarit
https://www.suomenuutiset.fi/sanna-antikaisen-kolumni-vornasen-pyssy-suututti-demarit-mutta-kuka-puhuu-totta/ Vornasen131619Nyt meni maku vas.liittoon, kun vaativat minimituntipalkkaa lakiin
Sehän tarkoittaa samalla myös maksimituntipalkkaa, koska kun laki on kerran laadittu, niin sitä on vaikea muuttaa. Työma591375Mun on pakko uskaltaa
Mikäköhän olisi pahin skenaario, jos vain laittaisin hänelle viestin, et haluan jutella meistä? Se, että hän vastaisi, e791291- 671280
Leikitään tavuleikkiä
Millaiset nimitavut muodostuvat jos yhdistät oman etunimesi ensimmäisen tavun ja kaipaamasi ihmisen etunimen ensimmäisen741256- 721237