<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>
+ <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>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
<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>
+
+ <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>
- - 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>
<li>understand software licenses
+ <li>consider sourceforge
+
+ <li>
</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)
- - 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
<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>
projects / homepage.git / blobdiff