An introduction to free software development, for those
interested in participating.
- Petter Reinholdtsen
pere@hungry.com
@@ -33,7 +33,7 @@
debian developer
-
initiater and current tech coordinator in skolelinux
+
initiator and current tech coordinator in skolelinux
currently employed at USIT, UiO
@@ -51,118 +51,206 @@
Richard M. Stallmann, FSF
-
Getting involved and helping out
- - use mailing lists
- - irc, wiki
+
So, you found a nice project on
+ Freshmeat, and want to help
+ improve it...
+
+
+
+ - get used to public review
+
- read the project documentation
+
- join the relevant mailing list, IRC channels, etc
+
- use mailing lists
+
- update the wiki
+
- get to know the source
+
- understand licensing issues
+
- learn to use the bug tracking system (bts)
+
- start with the non-coding stuff (translations, documentation)
+
- do not take it personally
+
+
Reporting bugs
+
This software suck. A lot!
+
+
+
+ - test if the bug exist the latest version
+
+
- do not report duplicate bugs, check the bts and mailing
+ lists
+
+
- document how to reproduce the bug, and include relevant
+ information. get output from valgrind, strace, gdb and
+ ltrace.
+
+
- include info on possible workarounds, and patches if you
+ can.
+
+ - add more info if the bug is already reported
+
+
- use the relevant bug reporting tool, such as bug-buddy (Gnome),
+ perlbug (Perl), reportbug (Debian) and sendpr (FreeBSD) or
+ use the projects bug reporting web site (bugzilla, request-tracker,
+ gnats, etc. check the project home page)
+
+
- remember to follow up your bug report.
+
+
+
+
an
+ example
+
+
Submitting patches
+
+
Fixing the problem is only half the work.
+
+
+ - if you can fix the problem you are facing, remember to let
+ the package author know about this.
+
- make a patch! (diff -u file.orig file.new >
+ myfix.diff)
+
- send the patch to the developer list, or possibly into the
+ bts (learn how the developers want it)
+
+
- do not forget to follow up the patch. Accept commend and
+ improve it until it is accepted by the developers.
+
+
- if you don't make sure the patch is accepted by the
+ developers, you will have to fix the same problem every time you
+ upgrade.
+
+
+
Joining a free software project
+
+
+ - start by checking out the bugs in the bts
+
- try to fix them
+
+
- give feedback into the bts on the reported bugs, after trying
+ to reproduce them.
- - painful
+
- go through the user documentation, and submit suggestions for
+ improvement
+
+
- be active on the mailing lists, provide answers to the
+ questions (and use references tot he user documentation, to save
+ everybody some work)
+
+
- make sure the code you write is self documenting, follow the
+ code policy and include enough comments to make the purpose of the
+ code easy to understand.
+
Starting a free software project
+
I got this idea for a piece of software...
+
+
+
+ - reuse when possible, prefer to improve existing
+ projects
+
+ - read other peoples code, download and test other peoples
+ programs
+
+ - understand software licenses
+
+
- consider sourceforge
+
+
+
+
This software suck. A lot! - Do not take it personally.
+
+
Use the best free development tools available
+
+
+ - compile with lots of warnings
+
- use existing libraries, but avoid to many dependencies
+
+
- learn to use debugging utilities (gdb, ddd, dmalloc,
+ valgrind, strace, ltrace, electric fence, fncchk, etc)
+
- learn to use profiling tools (kprof, gprof, etc)
+
- write automatic self testing
+
+
- do automatic coverage testing to check the quality of the
+ self test
+
+
+
+
Running a successful free software project I
+
+
+
+ - be responsive to comments and suggestions
+
- write down where you want the project to go
+
- do not accept every change. make sure you like it first
+
+
- let everyone work on the things that interests them, use the
+ carrot, as you have no whip
+
- set up and use a bts
+
+
+
+
Running a successful free software project II
+
+
+
+ - create web pages for your project, include screen shots, a
+ short summary and who to contact for more info
+
+
- remember to include a README file in the tarball. it should
+ include the home page URL, the download site URL,
+ a short description of the project and where to send bug reports
+ and patches
+ - involve the public mailing lists in the decision making
+
- automate everything
+
+
- set up system for public review of changes (anonymous CVS,
+ commit emails)
+
- communicate the intention behind the choice of license
+
+
+
As the project grows larger
+
+
Leading by example is your only option.
+
- - Reuse when possible, improve existing projects
-
- -
-
- - avoid starting from scratch, reuse an existing project if
- possible.
-
-
-
-
- - 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
+
- communicate the project plan to all project members
+
- try to reduce friction and avoid hard language
+
- keep track of what everyone is working on
+
Conclusion
+
+
+ - working on free software is very rewarding and challenging
+
+
- nobody owns you a favour, get used to it
+
+
- do it for your own gain, not to get rewards from others
+
+
+
References
+
+
Thank you very much
Questions?