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     <h2>Getting involved and helping out</h2>
  56
  57     <p>So, you found a nice project on Freshmeat, and want to help
  58       improve it...</p>
  59
  60     <ul>
  61
  62       <li>get used to public review
  63       <li>read the project documentation
  64       <li>join the relevant mailing list, IRC channels, etc
  65       <li>use mailing lists
  66       <li>irc, wiki
  67       <li>get to know the source
  68       <li>understand licensing issues
  69       <li>learn to use the bug tracking system (bts)
  70       <li>start with the non-coding stuff (translations, documentation)
  71       <li>do not take it personally
  72
  73     </ul>
  74
  75     <h2>Reporting bugs</h2>
  76
  77     <p>This software suck.  A lot!</p>
  78
  79     <ul>
  80
  81       <li>test if the bug exist the latest version
  82
  83       <li>do not report duplicate bugs, check the bts and mailing
  84       lists
  85
  86       <li>document how to reproduce the bug, and include relevant
  87         information.  get output from valgrind, strace, gdb and
  88         ltrace.
  89
  90       <li>include info on possible workarounds, and patches if you
  91       can.</li>
  92
  93       <li>add more info if the bug is already reported
  94
  95       <li>use the relevang bug reporting tool, such as bug-buddy (Gnome),
  96       perlbug (Perl), reportbug (Debian) and sendpr (FreeBSD) or
  97       use the projects bug reporting web site (bugzilla, request-tracker,
  98       gnats, etc. check the project home page)
  99
 100       <li>remember to follow up your bug report.
 101
 102     </ul>
 103
 104     <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306147">an
 105     example</a>
 106
 107     <h2>Submitting patches</h2>
 108
 109     <p>Fixing the problem is only half the work.</p>
 110
 111     <ul>
 112       <li>if you can fix the problem you are facing, remember to let
 113         the package author know about this.
 114       <li>make a patch! (<tt>patch -u file.orig file.new >
 115       myfix.diff</tt>)
 116       <li>send the patch to the developer list, or possibly into the
 117       bts (learn how the developers want it)
 118
 119       <li>do not forget to follow up the patch.  Accept commend and
 120       improve it until it is accepted by the developers.
 121
 122       <li>if you don't make sure the patch is accepted by the
 123       developers, you will have to fix the same problem every time you
 124       upgrade.
 125
 126     </ul>
 127
 128     <h2>Joining a free software project</h2>
 129
 130     <li>start by checking out the bugs in the btw
 131     <li>try to fix them
 132
 133     <li>give feedback into the bts on the reported bugs, after trying
 134     to reproduce
 135     them.
 136
 137 - aktiv prosjektdeltager
 138
 139   - fiks feilene som er rapportert i bugrapport-systemet (prosjektet
 140     _har_ et feilrapportsystem, ikke sant?)
 141   - Test og gi tilbakemelding på rapporterte feil.
 142   - sørg for at brukerdokumentasjonen er oppdatert, og henvis til
 143     denne (så slipper du ekstraarbeide)
 144   - sørg for at kildekoden du lager er selvdokumenterende, følger
 145     kode-policy og har akkurat nok kommentarer til at formålet med
 146     koden er lett å forstå
 147
 148     <h2>Starting a free software project</h2>
 149
 150     <p>I got this idea for a piece of software...</p>
 151
 152     <ul>
 153
 154       <li>reuse when possible, prefer to improve existing
 155       projects</li>
 156
 157       <li>read other peoples code, download and test other peoples
 158       programs</li>
 159
 160       <li>understand software licenses
 161
 162       <li>consider sourceforge
 163
 164       <li>
 165
 166     </ul>
 167
 168      - tools
 169    - compiler
 170    - libraries
 171    - debugging utilities (gdb, ddd, dmalloc, valgrind, strace, ltrace,
 172      electric fence, fncchk, etc)
 173
 174
 175     <p>This software suck.  A lot! - Do not take it personally.</p>
 176
 177     <h2>Running a successful free software project</h2>
 178
 179     <ul>
 180
 181       <li>write down where you want the project to go
 182       <li>do not accept every change.  make sure you like it first
 183
 184       <li>let everyone work on the things that interests them, use the
 185       carrot, as you have no whip
 186       <li>set up and use a bts
 187       <li>create web pages for your project, include screen shots, a
 188       short summary and who to contact for more info
 189
 190       <li>remember to include a README file in the tarball.  it should
 191       include the home page URL, the download site URL,
 192       a short description of the project and where to send bug reports
 193       and patches</li>
 194       <li>involve the public mailing lists in the decision making
 195       <li>automate everything
 196
 197       <li>set up system for public review of changes (anonymous CVS,
 198       commit emails)
 199       <li>communicate the intention behind the choice of license
 200     </ul>
 201
 202 - prosjektleder
 203
 204     - hold oversikt over hvem som gjør hva
 205     - kommuniser prosjektplanen til alle prosjektdeltagerne
 206
 207     <h2>Conclusion</h2>
 208
 209     <ul>
 210
 211       <li>working on free software is very rewarding and challenging
 212
 213       <li>nobody owns you a fawour
 214
 215       <li>
 216
 217     </ul>
 218
 219     <h2>References</h2>
 220
 221     <h2>Thank you very much</h2>
 222
 223     <h3>Questions?</h3>
 224
 225   </body>
 226 </html>