X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/394c6aa8fc7aa1fa95dd6579158593ebe352d92c..93ddf11b60fb9f5875e9e5dfd4c1ba034b6f60e9:/mypapers/free-sw-devel/free-sw-devel.html
diff --git a/mypapers/free-sw-devel/free-sw-devel.html b/mypapers/free-sw-devel/free-sw-devel.html
index d44fea8ed5..e911b2e13a 100644
--- a/mypapers/free-sw-devel/free-sw-devel.html
+++ b/mypapers/free-sw-devel/free-sw-devel.html
@@ -13,7 +13,7 @@
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
@@ -54,19 +54,20 @@
Getting involved and helping out
-
So, you found a nice project on Freshmeat, and want to help
- improve the project...
+
So, you found a nice project on
+ Freshmeat, and want to help
+ improve it...
-
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
+
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.
+
+
+
+ - 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?