Current status.

[homepage.git] / mypapers / free-sw-devel / free-sw-devel.html

diff --git a/mypapers/free-sw-devel/free-sw-devel.html b/mypapers/free-sw-devel/free-sw-devel.html
index d44fea8ed5340220ae7f64cf30dcd63d44645ef4..75d2bd1a88ec0078169a5f79f6a74a6bfb80f79f 100644 (file)
--- a/mypapers/free-sw-devel/free-sw-devel.html
+++ b/mypapers/free-sw-devel/free-sw-devel.html
@@ -55,18 +55,18 @@
     <h2>Getting involved and helping out</h2>
 
     <p>So, you found a nice project on Freshmeat, and want to help
     <h2>Getting involved and helping out</h2>
 
     <p>So, you found a nice project on Freshmeat, and want to help

-      improve the project...</p>
+      improve it...</p>

 
     <ul>
 
 
     <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>irc, wiki
       <li>get to know the source
       <li>understand licensing issues
       <li>read the project documentation
       <li>join the relevant mailing list, IRC channels, etc
       <li>use mailing lists
       <li>irc, wiki
       <li>get to know the source
       <li>understand licensing issues

-      <li>get used to for public review
-      <li>learn to use the bug tracking system
+      <li>learn to use the bug tracking system (bts)

       <li>start with the non-coding stuff (translations, documentation)
       <li>do not take it personally
 
       <li>start with the non-coding stuff (translations, documentation)
       <li>do not take it personally
 


@@ -76,33 +76,74 @@
 
     <p>This software suck.  A lot!</p>
 
 
     <p>This software suck.  A lot!</p>
 

-    - do not report duplicate bugs
-    - document how to reproduce the bug
-    - include relevant information
-
-- 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
+    <ul>
+
+      <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>include info on possible workarounds, and patches if you
+      can.</li>
+
+      <li>add more info if the bug is already reported
+
+      <li>use the relevang 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)
+
+      <li>remember to follow up your bug report.
+
+    </ul>

 
     <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306147">an
     example</a>
 
     <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>patch -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>
 
     
     <h2>Joining a free software project</h2>
 

-    - painful
+    <li>start by checking out the bugs in the btw
+    <li>try to fix them
+
+    <li>give feedback into the bts on the reported bugs, after trying
+    to reproduce
+    them.
+
+- 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å

 
     <h2>Starting a free software project</h2>
 
 
     <h2>Starting a free software project</h2>
 


@@ -118,69 +159,46 @@
 
       <li>understand software licenses
 
 
       <li>understand software licenses
 

+      <li>consider sourceforge
+
+      <li>

        
     </ul>
 
        
     </ul>
 

-    <h2>Running a successful free software project</h2>
-
-      - 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
-    - set up a bug tracking systems
-    - create web pages
-      - screen shots
-      - short summary
-      - who to contact for more info
-    - include a README in the tarball
-      - home page URL
-      - download site URL
-      - short description
-      - where to send bug reports and patches
-
- - public review (anonymous CVS, commit emails)
- - licenses
- - give well-formed bug reports, and include a patch if possible
- - consider sourceforge
- - tools
+     - tools

    - compiler
    - libraries
    - debugging utilities (gdb, ddd, dmalloc, valgrind, strace, ltrace,
      electric fence, fncchk, etc)
    - 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
-
-
-- 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.

 
 

+    <p>This software suck.  A lot! - Do not take it personally.</p>
+    
+    <h2>Running a successful free software project</h2>

 
 

-- 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å
+    <ul>

 
 

+      <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
+      <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>
+    

 - prosjektleder
 
     - hold oversikt over hvem som gjør hva
 - prosjektleder
 
     - hold oversikt over hvem som gjør hva


@@ -188,6 +206,16 @@
 
     <h2>Conclusion</h2>
 
 
     <h2>Conclusion</h2>
 

+    <ul>
+
+      <li>working on free software is very rewarding and challenging
+
+      <li>nobody owns you a fawour
+
+      <li>
+      
+    </ul>
+

     <h2>References</h2>
 
     <h2>Thank you very much</h2>
     <h2>References</h2>
 
     <h2>Thank you very much</h2>