X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/92333f9718a7ba93615e542fc427c44443d1f76a..93ddf11b60fb9f5875e9e5dfd4c1ba034b6f60e9:/mypapers/free-sw-devel/free-sw-devel.html?ds=sidebyside

diff --git a/mypapers/free-sw-devel/free-sw-devel.html b/mypapers/free-sw-devel/free-sw-devel.html
index 5bf544682a..e911b2e13a 100644
--- a/mypapers/free-sw-devel/free-sw-devel.html
+++ b/mypapers/free-sw-devel/free-sw-devel.html
@@ -13,7 +13,7 @@
     <p>An introduction to free software development, for those
       interested in participating.</p>
 
-    <p><tt><a href="free-sw-devel.html">http://www.hungry.com/~pere/.../free-sw-devel.html</a></tt></p>
+    <p><tt><a href="http://www.hungry.com/~pere/mypapers/free-sw-devel/free-sw-devel.html">http://www.hungry.com/~pere/mypapers/free-sw-devel/free-sw-devel.html</a></tt></p>
 
     <div class="presenter">Petter Reinholdtsen
       <br>pere@hungry.com
@@ -33,130 +33,224 @@
 
       <li>debian developer</li>
 
-      <li>initiater and current tech coordinator in skolelinux</li>
+      <li>initiator and current tech coordinator in skolelinux</li>
+
+      <li>currently employed at USIT, UiO</li>
 
     </ul>
 
-    <h2>What is free software</h2>
+    <h2>Free Software - user freedom</h2>
+
+    <ul>
 
-    - user freedom
-     - freedom to use
-     - freedom to modify
-     - freedom to distribute
+      <li>freedom to run the program as you wish for any purpose</li>
+      <li>freedom to study and change the source code as you wish</li>
+      <li>freedom to make and redistribute copies</li>
+      <li>freedom to publish modified versions</li>
+
+    </ul>
 
-      freedom to run the program as you wish for any purpose, freedom
-to study and change the source code as you wish, freedom to make and
-redistribute copies, and freedom to publish modified versions.
+    <p><em>Richard M. Stallmann, FSF</em></p>
 
     <h2>Getting involved and helping out</h2>
 
-    - use mailing lists
+    <p>So, you found a nice project on
+      <a href="http://freshmeat.net/">Freshmeat</a>, and want to help
+      improve it...</p>
 
-    <h2>Joining a free software project</h2>
+    <ul>
+
+      <li>get used to public review
+      <li>read the project documentation
+      <li>join the relevant mailing list, IRC channels, etc
+      <li>use mailing lists
+      <li>update the wiki
+      <li>get to know the source
+      <li>understand licensing issues
+      <li>learn to use the bug tracking system (bts)
+      <li>start with the non-coding stuff (translations, documentation)
+      <li>do not take it personally
+
+    </ul>
 
-    - painful
+    <h2>Reporting bugs</h2>
 
-    <h2>Making your own project</h2>
+    <p>This software suck.  A lot!</p>
 
     <ul>
 
-      <li>Reuse when possible, improve existing projects</li>
+      <li>test if the bug exist the latest version
+      
+      <li>do not report duplicate bugs, check the bts and mailing
+      lists
+      
+      <li>document how to reproduce the bug, and include relevant
+        information.  get output from valgrind, strace, gdb and
+        ltrace.
 
-      <li>
+      <li>include info on possible workarounds, and patches if you
+      can.</li>
 
-    - avoid starting from scratch, reuse an existing project if
-      possible.
+      <li>add more info if the bug is already reported
 
+      <li>use the relevant bug reporting tool, such as bug-buddy (Gnome),
+      perlbug (Perl), reportbug (Debian) and sendpr (FreeBSD) or
+      use the projects bug reporting web site (bugzilla, request-tracker,
+      gnats, etc. check the project home page)
 
-    <h2>Reporting bugs</h2>
+      <li>remember to follow up your bug report.
+
+    </ul>
+
+    <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306147">an
+    example</a>
+
+    <h2>Submitting patches</h2>
+
+    <p>Fixing the problem is only half the work.</p>
+
+    <ul>
+      <li>if you can fix the problem you are facing, remember to let
+        the package author know about this.
+      <li>make a patch! (<tt>diff -u file.orig file.new >
+      myfix.diff</tt>)
+      <li>send the patch to the developer list, or possibly into the
+      bts (learn how the developers want it)
+
+      <li>do not forget to follow up the patch.  Accept commend and
+      improve it until it is accepted by the developers.
+
+      <li>if you don't make sure the patch is accepted by the
+      developers, you will have to fix the same problem every time you
+      upgrade.
+
+    </ul>      
+    
+    <h2>Joining a free software project</h2>
+    <ul>
+
+    <li>start by checking out the bugs in the bts
+    <li>try to fix them
+
+    <li>give feedback into the bts on the reported bugs, after trying
+    to reproduce them.
+
+    <li>go through the user documentation, and submit suggestions for
+    improvement
+
+    <li>be active on the mailing lists, provide answers to the
+    questions (and use references tot he user documentation, to save
+    everybody some work)
+
+    <li>make sure the code you write is self documenting, follow the
+    code policy and include enough comments to make the purpose of the
+    code easy to understand.
+    </ul>
 
     <h2>Starting a free software project</h2>
 
- - public review (anonymous CVS, commit emails)
- - bug tracking systems
- - licenses
- - download and test other peoples the programs
- - read other peoples code
- - give well-formed bug reports, and include a patch if possible
- - let everyone work on the things that interests them
- - do not accept every change.  make sure you like it first
- - write down where you want the project to go
- - web pages
-   - screen shots
-   - short summary
-   - who to contact for more info
- - source README
-   - home page URL
-   - download site URL
-   - short description
-   - where to send bug reports and patches
- - consider sourceforge
- - tools
-   - compiler
-   - libraries
-   - debugging utilities (gdb, ddd, dmalloc, valgrind, strace, ltrace,
-     electric fence, fncchk, etc)
- - avoid duplicate work (check freshmeat)
-
-
-- bruker
-
-  - hold deg til de store distribusjenene
-  - hvis du finner feil
-    - fortell din lokale sysadmin om feilen, og be personen teste
-      nyere versjoner og/eller å skrive en feilrapport
-
-- sysadmin/feilrapportør
-
-  - Hvis du finner en feil
-    - søk i bug-databasen til produktet om dette er en kjent feil
-    - hvis ikke, test siste utgave lokalt
-    - hvis feilen fremdeles er der, og er gjenproduserbar, send en
-      feilrapport (valgrind, strace, gdb, ltrace)
-    - hvis feilen ikke er fikset, men utviklerne er klar over denne,
-      send en feilrapport til!
-    - sørg for at feilrapporten inneholder nødvendig informasjon for å
-      gjenprodusere feilen og hvordan systemet ditt er konfigurert
-    - bruk gjerne feilrapporteringsverktøy som bug-buddy (Gnome),
-      perlbug (Perl), reportbug (Debian) sendpr (FreeBSD), eller
-      produktets feilrapporterings-webside (bugzilla, request-tracker,
-      gnats e.l. Se på prosjektets hjemmeside)
-    - husk å følge opp feilrapporten din
-
-
-- patch-bidragsyter
-
-  - Hvis du har muligheten til å rette feilen selv, pass på fortelle
-    prosjekt-delagerene om fiksen
-  - lag en patch! (patch -u fil.org fil.ny > minfiks.patch)
-  - send denne til utvikler-mailinglisten, og følg med om den blir
-    inkludert, eller om den krever mere fiksing.
-  - ikke "glem" en patch. blir den ikke akseptert, sørg for å fikse
-    patchen så den blir akseptert.
-  - "glemte" patcher _vil_ skape merarbeide for deg neste gang
-    programmet skal oppgraderes.
-
-
-- aktiv prosjektdeltager
-
-  - fiks feilene som er rapportert i bugrapport-systemet (prosjektet
-    _har_ et feilrapportsystem, ikke sant?)
-  - Test og gi tilbakemelding på rapporterte feil.
-  - sørg for at brukerdokumentasjonen er oppdatert, og henvis til
-    denne (så slipper du ekstraarbeide)
-  - sørg for at kildekoden du lager er selvdokumenterende, følger
-    kode-policy og har akkurat nok kommentarer til at formålet med
-    koden er lett å forstå
-
-- prosjektleder
-
-    - hold oversikt over hvem som gjør hva
-    - kommuniser prosjektplanen til alle prosjektdeltagerne
+    <p>I got this idea for a piece of software...</p>
+
+    <ul>
+
+      <li>reuse when possible, prefer to improve existing
+      projects</li>
+
+      <li>read other peoples code, download and test other peoples
+      programs</li>
+
+      <li>understand software licenses
+
+      <li>consider sourceforge
+
+    </ul>
+
+    <p>This software suck.  A lot! - Do not take it personally.</p>
+
+    <h2>Use the best free development tools available</h2>
+
+    <ul>
+      <li>compile with lots of warnings
+      <li>use existing libraries, but avoid to many dependencies
+
+      <li>learn to use debugging utilities (gdb, ddd, dmalloc,
+	valgrind, strace, ltrace, electric fence, fncchk, etc)
+      <li>learn to use profiling tools (kprof, gprof, etc)
+      <li>write automatic self testing
+
+      <li>do automatic coverage testing to check the quality of the
+	self test
+
+    </ul>
+    
+    <h2>Running a successful free software project I</h2>
+
+    <ul>
+
+      <li>be responsive to comments and suggestions
+      <li>write down where you want the project to go
+      <li>do not accept every change.  make sure you like it first
+
+      <li>let everyone work on the things that interests them, use the
+      carrot, as you have no whip
+      <li>set up and use a bts
+
+    </ul>
+
+    <h2>Running a successful free software project II</h2>
+
+    <ul>
+
+      <li>create web pages for your project, include screen shots, a
+      short summary and who to contact for more info
+      
+      <li>remember to include a README file in the tarball.  it should
+      include the home page URL, the download site URL,
+      a short description of the project and where to send bug reports
+      and patches</li>
+      <li>involve the public mailing lists in the decision making
+      <li>automate everything
+
+      <li>set up system for public review of changes (anonymous CVS,
+      commit emails)
+      <li>communicate the intention behind the choice of license
+    </ul>
+
+    <h2>As the project grows larger</h2>
+
+    <p>Leading by example is your only option.</p>
+
+    <ul>
+
+      <li>communicate the project plan to all project members
+      <li>try to reduce friction and avoid hard language
+      <li>keep track of what everyone is working on
+    </ul>
 
     <h2>Conclusion</h2>
 
+    <ul>
+
+      <li>working on free software is very rewarding and challenging
+
+      <li>nobody owns you a favour, get used to it
+
+      <li>do it for your own gain, not to get rewards from others
+      
+    </ul>
+
     <h2>References</h2>
 
+    <ul>
+
+      <li>"The Practice of Programming" by Kernighan and Pike.
+
+      <li>"<a href="http://opensource.mit.edu/online_paper">Free /
+      Open Source Research Community - online papers</a>,
+      <tt>http://opensource.mit.edu/online_paper</tt></li>
+
+    </ul>
+
     <h2>Thank you very much</h2>
 
     <h3>Questions?</h3>