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>contributor to several projects (linux, glibc, kde, debian,
  29         mapserver, openstreetmap.org, skolelinux, etc)</li>
  30
  31       <li>debian developer</li>
  32
  33       <li>initiater and current tech coordinator in skolelinux</li>
  34
  35     <h2>What is free software</h2>
  36
  37     - user freedom
  38      - freedom to use
  39      - freedom to modify
  40      - freedom to distribute
  41
  42     <h2>Rookie checkin</h2>
  43
  44     <h2>TBPITW - The Best project in the World</h2>
  45
  46     - avoid starting from scratch, reuse an existing project if
  47       possible.
  48
  49     <h2>Joining a free software project</h2>
  50
  51     <h2>Starting a free software project</h2>
  52
  53  - use mailing lists
  54  - public review (anonymous CVS, commit emails)
  55  - bug tracking systems
  56  - licenses
  57  - download and test other peoples the programs
  58  - read other peoples code
  59  - give well-formed bug reports, and include a patch if possible
  60  - let everyone work on the things that interests them
  61  - do not accept every change.  make sure you like it first
  62  - write down where you want the project to go
  63  - web pages
  64    - screen shots
  65    - short summary
  66    - who to contact for more info
  67  - source README
  68    - home page URL
  69    - download site URL
  70    - short description
  71    - where to send bug reports and patches
  72  - consider sourceforge
  73  - tools
  74    - compiler
  75    - libraries
  76    - debugging utilities (gdb, ddd, dmalloc, valgrind, electric fence,
  77      fncchk, etc)
  78  - avoid duplicate work (check freshmeat)
  79
  80
  81 - bruker
  82
  83   - hold deg til de store distribusjenene
  84   - hvis du finner feil
  85     - fortell din lokale sysadmin om feilen, og be personen teste
  86       nyere versjoner og/eller å skrive en feilrapport
  87
  88 - sysadmin/feilrapportør
  89
  90   - Hvis du finner en feil
  91     - søk i bug-databasen til produktet om dette er en kjent feil
  92     - hvis ikke, test siste utgave lokalt
  93     - hvis feilen fremdeles er der, og er gjenproduserbar, send en
  94       feilrapport
  95     - hvis feilen ikke er fikset, men utviklerne er klar over denne,
  96       send en feilrapport til!
  97     - sørg for at feilrapporten inneholder nødvendig informasjon for å
  98       gjenprodusere feilen og hvordan systemet ditt er konfigurert
  99     - bruk gjerne feilrapporteringsverktøy som bug-buddy (Gnome),
 100       perlbug (Perl), reportbug (Debian) sendpr (FreeBSD), eller
 101       produktets feilrapporterings-webside (bugzilla, request-tracker,
 102       gnats e.l. Se på prosjektets hjemmeside)
 103     - husk å følge opp feilrapporten din
 104
 105
 106 - patch-bidragsyter
 107
 108   - Hvis du har muligheten til å rette feilen selv, pass på fortelle
 109     prosjekt-delagerene om fiksen
 110   - lag en patch! (patch -u fil.org fil.ny > minfiks.patch)
 111   - send denne til utvikler-mailinglisten, og følg med om den blir
 112     inkludert, eller om den krever mere fiksing.
 113   - ikke "glem" en patch. blir den ikke akseptert, sørg for å fikse
 114     patchen så den blir akseptert.
 115   - "glemte" patcher _vil_ skape merarbeide for deg neste gang
 116     programmet skal oppgraderes.
 117
 118
 119 - aktiv prosjektdeltager
 120
 121   - fiks feilene som er rapportert i bugrapport-systemet (prosjektet
 122     _har_ et feilrapportsystem, ikke sant?)
 123   - Test og gi tilbakemelding på rapporterte feil.
 124   - sørg for at brukerdokumentasjonen er oppdatert, og henvis til
 125     denne (så slipper du ekstraarbeide)
 126   - sørg for at kildekoden du lager er selvdokumenterende, følger
 127     kode-policy og har akkurat nok kommentarer til at formålet med
 128     koden er lett å forstå
 129
 130 - prosjektleder
 131
 132     <h2>Conclusion</h2>
 133
 134     <h2>References</h2>
 135
 136     <h2>Thank you very much</h2>
 137
 138     <h3>Questions?</h3>
 139
 140   </body>
 141 </html>