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