Citat:
Yep, imam ih tuce submit-ovanih samo za kernel :) Najteze je kada nadjes bug da pruzis kvalitetan feedback, moras da imas paket iskompajliran sa debugging simbolima da bi trace ista znacio (za kernel debugging opcije u kernel hacking sekciji odvrnute), da znas kako tacno da reprodukujes bug i eventualno da znas zbog cega se javlja (tj bitno je da znas protiv kog paketa ili grane treba da podneses report).
Bas su te iscimali. Mislim da je precizan opis verzije kernela uz program koji reprodukuje gresku sasvim dovoljan. Pa nek sami svlache sa svn-a problematicnu verziju i reprodukuju bug. Uz stek trejsove si verovatno mogao i sam da napises fix... no, nije to tvoj posao. Kernel maintaineri treba i da istestiraju kako svi dosadasnji fixevi medjusobno interaguju i da li kernel ostaje stabilan. Mozda bas postoji neki deo koda koji se oslanja na pogresno ponasanje modula koji si fixovao (ima zavisnost ka bugu).
Citat:
Iz ovog razloga je po meni bilo bolje zadati ovakav neki task, nego da juris gresku u dokumentaciji :)
Zadatak studenata obuhvata i scenario koji si opisao. Bilo kakvo ponasanje programa van specifikacije (kresiranje pogotovo) je greska koju valja prijaviti.
Citat:
Jos kada te podu'vate oni ludi kernel programeri - pa kad ti daju patch koji moras rucno da backportujes ili "forwardportujes" jos gore :)
Mda... zabava sa verzijama... uglavnom ni to ne bi trebalo da bude tvoj posao. Nakon sto posaljes bug report, prosto sacekaj novu inkarnaciju produkcijskog softvera. U njemu ce biti ukljuchen tvoj fix sa jos morem ispravljenih gluposti i proverenim medjusobnim zavisnostima patchovanih 'modula'.
Ipak, sve ovo zajedno je velika prednost open sors razvoja -- kvalitetan feedback. Kao sto rece Eric Raymond u "Katedrali i Bazaru" prednost otvorenog koda nije u tome sto svako mozhe da prchka po njemu ili da ga studira, vec sto se dobija pristup odlichnom testing auditorijumu, cime se pospesuje zivotni ciklus softverskog razvoja.
