+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+ <head>
+ <link rel="stylesheet" href="../mrtg-td/slides.css" type="text/css">
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+ <meta name="Language" content="en">
+ <meta name="Author" content="Petter Reinholdtsen">
+ </head>
+ <body>
+
+ <h1>Free software development for beginners</h1>
+
+ <p>An introduction to free software development, for those
+ interested in participating.</p>
+
+ <p><tt><a href="free-sw-devel.html">http://www.hungry.com/~pere/.../free-sw-devel.html</a></tt></p>
+
+ <div class="presenter">Petter Reinholdtsen
+ <br>pere@hungry.com
+ <br>IFI/UiO, 2004-04-27</div>
+
+ <h2>What is free software</h2>
+
+ - user freedom
+
+ - use mailing lists
+ - 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, 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
+ - 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
+
+ <h2>Conclusion</h2>
+
+ <h2>References</h2>
+
+ <h2>Thank you very much</h2>
+
+ <h3>Questions?</h3>
+
+ </body>
+</html>
projects / homepage.git / commitdiff