Free software development for beginners

An introduction to free software development, for those interested in participating.

http://www.hungry.com/~pere/mypapers/free-sw-devel/free-sw-devel.html

Petter Reinholdtsen
pere@hungry.com
IFI/UiO, Forskningsparken rom 207 2004-04-27

Who am I

Free Software - user freedom

Richard M. Stallmann, FSF

Getting involved and helping out

So, you found a nice project on Freshmeat, and want to help improve the project...

Reporting bugs

This software suck. A lot!

- do not report duplicate bugs - document how to reproduce the bug - include relevant information - sysadmin/feilrapportør - Hvis du finner en feil - søk i bug-databasen til produktet om dette er en kjent feil - hvis ikke, test siste utgave lokalt - hvis feilen fremdeles er der, og er gjenproduserbar, send en feilrapport (valgrind, strace, gdb, ltrace) - hvis feilen ikke er fikset, men utviklerne er klar over denne, send en feilrapport til! - sørg for at feilrapporten inneholder nødvendig informasjon for å gjenprodusere feilen og hvordan systemet ditt er konfigurert - bruk gjerne feilrapporteringsverktøy som bug-buddy (Gnome), perlbug (Perl), reportbug (Debian) sendpr (FreeBSD), eller produktets feilrapporterings-webside (bugzilla, request-tracker, gnats e.l. Se på prosjektets hjemmeside) - husk å følge opp feilrapporten din an example

Joining a free software project

- painful

Starting a free software project

I got this idea for a piece of software...

Running a successful free software project

- let everyone work on the things that interests them - do not accept every change. make sure you like it first - write down where you want the project to go - set up a bug tracking systems - create web pages - screen shots - short summary - who to contact for more info - include a README in the tarball - home page URL - download site URL - short description - where to send bug reports and patches - public review (anonymous CVS, commit emails) - licenses - give well-formed bug reports, and include a patch if possible - consider sourceforge - tools - compiler - libraries - debugging utilities (gdb, ddd, dmalloc, valgrind, strace, ltrace, electric fence, fncchk, etc) - avoid duplicate work (check freshmeat) - bruker - hold deg til de store distribusjenene - hvis du finner feil - fortell din lokale sysadmin om feilen, og be personen teste nyere versjoner og/eller å skrive en feilrapport - patch-bidragsyter - Hvis du har muligheten til å rette feilen selv, pass på fortelle prosjekt-delagerene om fiksen - lag en patch! (patch -u fil.org fil.ny > minfiks.patch) - send denne til utvikler-mailinglisten, og følg med om den blir inkludert, eller om den krever mere fiksing. - ikke "glem" en patch. blir den ikke akseptert, sørg for å fikse patchen så den blir akseptert. - "glemte" patcher _vil_ skape merarbeide for deg neste gang programmet skal oppgraderes. - aktiv prosjektdeltager - fiks feilene som er rapportert i bugrapport-systemet (prosjektet _har_ et feilrapportsystem, ikke sant?) - Test og gi tilbakemelding på rapporterte feil. - sørg for at brukerdokumentasjonen er oppdatert, og henvis til denne (så slipper du ekstraarbeide) - sørg for at kildekoden du lager er selvdokumenterende, følger kode-policy og har akkurat nok kommentarer til at formålet med koden er lett å forstå - prosjektleder - hold oversikt over hvem som gjør hva - kommuniser prosjektplanen til alle prosjektdeltagerne

Conclusion

References

Thank you very much

Questions?