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/.../free-sw-devel.html</a></tt></p>
  17
  18     <div class="presenter">Petter Reinholdtsen
  19       <br>pere@hungry.com
  20       <br>IFI/UiO, 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     </ul>
  39
  40     <h2>What is free software</h2>
  41
  42     - user freedom
  43      - freedom to use
  44      - freedom to modify
  45      - freedom to distribute
  46
  47       freedom to run the program as you wish for any purpose, freedom
  48 to study and change the source code as you wish, freedom to make and
  49 redistribute copies, and freedom to publish modified versions.
  50
  51     <h2>Getting involved and helping out</h2>
  52
  53     - use mailing lists
  54
  55     <h2>Joining a free software project</h2>
  56
  57     - painful
  58
  59     <h2>Making your own project</h2>
  60
  61     <ul>
  62
  63       <li>Reuse when possible, improve existing projects</li>
  64
  65       <li>
  66
  67     - avoid starting from scratch, reuse an existing project if
  68       possible.
  69
  70
  71     <h2>Reporting bugs</h2>
  72
  73     <h2>Starting a free software project</h2>
  74
  75  - public review (anonymous CVS, commit emails)
  76  - bug tracking systems
  77  - licenses
  78  - download and test other peoples the programs
  79  - read other peoples code
  80  - give well-formed bug reports, and include a patch if possible
  81  - let everyone work on the things that interests them
  82  - do not accept every change.  make sure you like it first
  83  - write down where you want the project to go
  84  - web pages
  85    - screen shots
  86    - short summary
  87    - who to contact for more info
  88  - source README
  89    - home page URL
  90    - download site URL
  91    - short description
  92    - where to send bug reports and patches
  93  - consider sourceforge
  94  - tools
  95    - compiler
  96    - libraries
  97    - debugging utilities (gdb, ddd, dmalloc, valgrind, strace, ltrace,
  98      electric fence, fncchk, etc)
  99  - avoid duplicate work (check freshmeat)
 100
 101
 102 - bruker
 103
 104   - hold deg til de store distribusjenene
 105   - hvis du finner feil
 106     - fortell din lokale sysadmin om feilen, og be personen teste
 107       nyere versjoner og/eller å skrive en feilrapport
 108
 109 - sysadmin/feilrapportør
 110
 111   - Hvis du finner en feil
 112     - søk i bug-databasen til produktet om dette er en kjent feil
 113     - hvis ikke, test siste utgave lokalt
 114     - hvis feilen fremdeles er der, og er gjenproduserbar, send en
 115       feilrapport (valgrind, strace, gdb, ltrace)
 116     - hvis feilen ikke er fikset, men utviklerne er klar over denne,
 117       send en feilrapport til!
 118     - sørg for at feilrapporten inneholder nødvendig informasjon for å
 119       gjenprodusere feilen og hvordan systemet ditt er konfigurert
 120     - bruk gjerne feilrapporteringsverktøy som bug-buddy (Gnome),
 121       perlbug (Perl), reportbug (Debian) sendpr (FreeBSD), eller
 122       produktets feilrapporterings-webside (bugzilla, request-tracker,
 123       gnats e.l. Se på prosjektets hjemmeside)
 124     - husk å følge opp feilrapporten din
 125
 126
 127 - patch-bidragsyter
 128
 129   - Hvis du har muligheten til å rette feilen selv, pass på fortelle
 130     prosjekt-delagerene om fiksen
 131   - lag en patch! (patch -u fil.org fil.ny > minfiks.patch)
 132   - send denne til utvikler-mailinglisten, og følg med om den blir
 133     inkludert, eller om den krever mere fiksing.
 134   - ikke "glem" en patch. blir den ikke akseptert, sørg for å fikse
 135     patchen så den blir akseptert.
 136   - "glemte" patcher _vil_ skape merarbeide for deg neste gang
 137     programmet skal oppgraderes.
 138
 139
 140 - aktiv prosjektdeltager
 141
 142   - fiks feilene som er rapportert i bugrapport-systemet (prosjektet
 143     _har_ et feilrapportsystem, ikke sant?)
 144   - Test og gi tilbakemelding på rapporterte feil.
 145   - sørg for at brukerdokumentasjonen er oppdatert, og henvis til
 146     denne (så slipper du ekstraarbeide)
 147   - sørg for at kildekoden du lager er selvdokumenterende, følger
 148     kode-policy og har akkurat nok kommentarer til at formålet med
 149     koden er lett å forstå
 150
 151 - prosjektleder
 152
 153     - hold oversikt over hvem som gjør hva
 154     - kommuniser prosjektplanen til alle prosjektdeltagerne
 155
 156     <h2>Conclusion</h2>
 157
 158     <h2>References</h2>
 159
 160     <h2>Thank you very much</h2>
 161
 162     <h3>Questions?</h3>
 163
 164   </body>
 165 </html>