Free software development for beginners
An introduction to free software development, for those
interested in participating.
http://www.hungry.com/~pere/.../free-sw-devel.html
Petter Reinholdtsen
pere@hungry.com
IFI/UiO, 2004-04-27
Who am I
- been involved in free software development since 1992
- programmer and system administrator
- past and current contributor to several projects (linux,
glibc, kde, debian-{edu, gis, java, cdd}, mapserver,
openstreetmap.org, skolelinux, etc)
- debian developer
- initiater and current tech coordinator in skolelinux
What is free software
- user freedom
- freedom to use
- freedom to modify
- freedom to distribute
freedom to run the program as you wish for any purpose, freedom
to study and change the source code as you wish, freedom to make and
redistribute copies, and freedom to publish modified versions.
Getting involved and helping out
- use mailing lists
Joining a free software project
- painful
Making your own project
- Reuse when possible, improve existing projects
-
- avoid starting from scratch, reuse an existing project if
possible.
Reporting bugs
Starting a free software project
- public review (anonymous CVS, commit emails)
- bug tracking systems
- licenses
- download and test other peoples the programs
- read other peoples code
- give well-formed bug reports, and include a patch if possible
- 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
- web pages
- screen shots
- short summary
- who to contact for more info
- source README
- home page URL
- download site URL
- short description
- where to send bug reports and patches
- 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
- 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
- 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?