--- /dev/null
+include ../../Makefile.latex
+
+IMAGES =
+
+DOCUMENT = free-sw-devel
+
+all: $(DOCUMENT).ps # $(DOCUMENT)-8.ps
+
+$(DOCUMENT).ps: $(DOCUMENT).dvi
+$(DOCUMENT).dvi: $(DOCUMENT).tex $(IMAGES)
+$(DOCUMENT)-8.ps: $(DOCUMENT).ps
+ psnup -8 -pa4 -r < $< > $@
+
+clean:
+ $(RM) *.log *.aux *~ *.eps *.bak
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+ <head>
+ <link rel="stylesheet" href="../mrtg-td/slides.css" type="text/css">
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+ <meta name="Language" content="en">
+ <meta name="Author" content="Petter Reinholdtsen">
+ </head>
+ <body>
+
+ <h1>Free software development for beginners</h1>
+
+ <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>
+
+ <div class="presenter">Petter Reinholdtsen
+ <br>pere@hungry.com
+ <br>IFI/UiO, 2004-04-27</div>
+
+ <h2>What is free software</h2>
+
+ - user freedom
+
+ - use mailing lists
+ - 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, 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
+ - 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
+
+ <h2>Conclusion</h2>
+
+ <h2>References</h2>
+
+ <h2>Thank you very much</h2>
+
+ <h3>Questions?</h3>
+
+ </body>
+</html>
--- /dev/null
+\documentclass[a4, landscape, semrot]{seminar}
+
+\usepackage{fancybox}
+\usepackage{graphicx}
+\usepackage{picinpar}
+
+\slideframe{Oval}
+
+\newcommand{\heading}[1]{%
+ \begin{center} \large\bf #1 \end{center}
+ \vspace{1ex minus 1ex}}
+
+\newpagestyle{MH}%
+ {Norwegian Unix User Group, Oslo, 2003-XX-XX \hfill \thepage}%
+ {Free software development for beginners
+ \hfill Petter Reinholdtsen $<$pere@hungry.com$>$}
+\pagestyle{MH}
+
+\rotateheaderstrue
+
+\begin{document}
+
+\begin{slide}
+
+%\begin{center}
+%\includegraphics[height=2cm]{soccer-logo-med}
+%\end{center}
+
+\heading{Free software development for beginners}
+
+\begin{center}
+Petter Reinholdtsen $<$pere@hungry.com$>$
+\end{center}
+
+An introduction to free software and how it is developed.
+
+\newslide
+
+\heading{What is free software}
+
+ - user freedom
+
+\newslide
+
+ - use mailing lists
+ - 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, electric fence,
+ fncchk, etc)
+ - avoid duplicate work (check freshmeat)
+
+\newslide
+
+\heading{Thank you}
+
+\begin{center}
+%\includegraphics[height=5cm]{soccer1}
+
+{\tt http://www.hungry.com/\~{}pere/}
+
+\end{center}
+\end{slide}
+\end{document}
--- /dev/null
+
+- 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
+ - 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
+
projects / homepage.git / commitdiff