mypapers/free-sw-devel/free-sw-devel.html

   1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
   2 <html>
   3   <head>
   4     <link rel="stylesheet" href="../mrtg-td/slides.css" type="text/css">
   5     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   6     <meta name="Language" content="en">
   7     <meta name="Author" content="Petter Reinholdtsen">
   8   </head>
   9   <body>
  10
  11     <h1>Free software development for beginners</h1>
  12
  13     <p>An introduction to free software development, for those
  14       interested in participating.</p>
  15
  16     <p><tt><a href="free-sw-devel.html">http://www.hungry.com/~pere/mypapers/free-sw-devel/free-sw-devel.html</a></tt></p>
  17
  18     <div class="presenter">Petter Reinholdtsen
  19       <br>pere@hungry.com
  20       <br>IFI/UiO, Forskningsparken rom 207 2004-04-27</div>
  21
  22     <h2>Who am I</h2>
  23
  24     <ul>
  25
  26       <li>been involved in free software development since 1992</li>
  27
  28       <li>programmer and system administrator</li>
  29
  30       <li>past and current contributor to several projects (linux,
  31         glibc, kde, debian-{edu, gis, java, cdd}, mapserver,
  32         openstreetmap.org, skolelinux, etc)</li>
  33
  34       <li>debian developer</li>
  35
  36       <li>initiater and current tech coordinator in skolelinux</li>
  37
  38       <li>currently employed at USIT, UiO</li>
  39
  40     </ul>
  41
  42     <h2>Free Software - user freedom</h2>
  43
  44     <ul>
  45
  46       <li>freedom to run the program as you wish for any purpose</li>
  47       <li>freedom to study and change the source code as you wish</li>
  48       <li>freedom to make and redistribute copies</li>
  49       <li>freedom to publish modified versions</li>
  50
  51     </ul>
  52
  53     <p><em>Richard M. Stallmann, FSF</em></p>
  54
  55
  56     <h2>Getting involved and helping out</h2>
  57
  58     - use mailing lists
  59     - irc, wiki
  60
  61     <h2>Reporting bugs</h2>
  62
  63     <h2>Joining a free software project</h2>
  64
  65     - painful
  66
  67     <h2>Starting a free software project</h2>
  68
  69     <ul>
  70
  71       <li>Reuse when possible, improve existing projects</li>
  72
  73       <li>
  74
  75     - avoid starting from scratch, reuse an existing project if
  76       possible.
  77
  78
  79
  80
  81  - public review (anonymous CVS, commit emails)
  82  - bug tracking systems
  83  - licenses
  84  - download and test other peoples the programs
  85  - read other peoples code
  86  - give well-formed bug reports, and include a patch if possible
  87  - let everyone work on the things that interests them
  88  - do not accept every change.  make sure you like it first
  89  - write down where you want the project to go
  90  - web pages
  91    - screen shots
  92    - short summary
  93    - who to contact for more info
  94  - source README
  95    - home page URL
  96    - download site URL
  97    - short description
  98    - where to send bug reports and patches
  99  - consider sourceforge
 100  - tools
 101    - compiler
 102    - libraries
 103    - debugging utilities (gdb, ddd, dmalloc, valgrind, strace, ltrace,
 104      electric fence, fncchk, etc)
 105  - avoid duplicate work (check freshmeat)
 106
 107
 108 - bruker
 109
 110   - hold deg til de store distribusjenene
 111   - hvis du finner feil
 112     - fortell din lokale sysadmin om feilen, og be personen teste
 113       nyere versjoner og/eller å skrive en feilrapport
 114
 115 - sysadmin/feilrapportør
 116
 117   - Hvis du finner en feil
 118     - søk i bug-databasen til produktet om dette er en kjent feil
 119     - hvis ikke, test siste utgave lokalt
 120     - hvis feilen fremdeles er der, og er gjenproduserbar, send en
 121       feilrapport (valgrind, strace, gdb, ltrace)
 122     - hvis feilen ikke er fikset, men utviklerne er klar over denne,
 123       send en feilrapport til!
 124     - sørg for at feilrapporten inneholder nødvendig informasjon for å
 125       gjenprodusere feilen og hvordan systemet ditt er konfigurert
 126     - bruk gjerne feilrapporteringsverktøy som bug-buddy (Gnome),
 127       perlbug (Perl), reportbug (Debian) sendpr (FreeBSD), eller
 128       produktets feilrapporterings-webside (bugzilla, request-tracker,
 129       gnats e.l. Se på prosjektets hjemmeside)
 130     - husk å følge opp feilrapporten din
 131
 132
 133 - patch-bidragsyter
 134
 135   - Hvis du har muligheten til å rette feilen selv, pass på fortelle
 136     prosjekt-delagerene om fiksen
 137   - lag en patch! (patch -u fil.org fil.ny > minfiks.patch)
 138   - send denne til utvikler-mailinglisten, og følg med om den blir
 139     inkludert, eller om den krever mere fiksing.
 140   - ikke "glem" en patch. blir den ikke akseptert, sørg for å fikse
 141     patchen så den blir akseptert.
 142   - "glemte" patcher _vil_ skape merarbeide for deg neste gang
 143     programmet skal oppgraderes.
 144
 145
 146 - aktiv prosjektdeltager
 147
 148   - fiks feilene som er rapportert i bugrapport-systemet (prosjektet
 149     _har_ et feilrapportsystem, ikke sant?)
 150   - Test og gi tilbakemelding på rapporterte feil.
 151   - sørg for at brukerdokumentasjonen er oppdatert, og henvis til
 152     denne (så slipper du ekstraarbeide)
 153   - sørg for at kildekoden du lager er selvdokumenterende, følger
 154     kode-policy og har akkurat nok kommentarer til at formålet med
 155     koden er lett å forstå
 156
 157 - prosjektleder
 158
 159     - hold oversikt over hvem som gjør hva
 160     - kommuniser prosjektplanen til alle prosjektdeltagerne
 161
 162     <h2>Conclusion</h2>
 163
 164     <h2>References</h2>
 165
 166     <h2>Thank you very much</h2>
 167
 168     <h3>Questions?</h3>
 169
 170   </body>
 171 </html>