]> pere.pagekite.me Git - homepage.git/blob - mypapers/free-sw-devel/free-sw-devel.html
Start på presentasjon.
[homepage.git] / 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/.../free-sw-devel.html</a></tt></p>
17
18 <div class="presenter">Petter Reinholdtsen
19 <br>pere@hungry.com
20 <br>IFI/UiO, 2004-04-27</div>
21
22 <h2>What is free software</h2>
23
24 - user freedom
25
26 - use mailing lists
27 - public review (anonymous CVS, commit emails)
28 - bug tracking systems
29 - licenses
30 - download and test other peoples the programs
31 - read other peoples code
32 - give well-formed bug reports, and include a patch if possible
33 - let everyone work on the things that interests them
34 - do not accept every change. make sure you like it first
35 - write down where you want the project to go
36 - web pages
37 - screen shots
38 - short summary
39 - who to contact for more info
40 - source README
41 - home page URL
42 - download site URL
43 - short description
44 - where to send bug reports and patches
45 - consider sourceforge
46 - tools
47 - compiler
48 - libraries
49 - debugging utilities (gdb, ddd, dmalloc, valgrind, electric fence,
50 fncchk, etc)
51 - avoid duplicate work (check freshmeat)
52
53
54 - bruker
55
56 - hold deg til de store distribusjenene
57 - hvis du finner feil
58 - fortell din lokale sysadmin om feilen, og be personen teste
59 nyere versjoner og/eller å skrive en feilrapport
60
61 - sysadmin/feilrapportør
62
63 - Hvis du finner en feil
64 - søk i bug-databasen til produktet om dette er en kjent feil
65 - hvis ikke, test siste utgave lokalt
66 - hvis feilen fremdeles er der, og er gjenproduserbar, send en
67 feilrapport
68 - hvis feilen ikke er fikset, men utviklerne er klar over denne,
69 send en feilrapport til!
70 - sørg for at feilrapporten inneholder nødvendig informasjon for å
71 gjenprodusere feilen og hvordan systemet ditt er konfigurert
72 - bruk gjerne feilrapporteringsverktøy som bug-buddy (Gnome),
73 perlbug (Perl), reportbug (Debian) sendpr (FreeBSD), eller
74 produktets feilrapporterings-webside (bugzilla, request-tracker,
75 gnats e.l. Se på prosjektets hjemmeside)
76 - husk å følge opp feilrapporten din
77
78
79 - patch-bidragsyter
80
81 - Hvis du har muligheten til å rette feilen selv, pass på fortelle
82 prosjekt-delagerene om fiksen
83 - lag en patch! (patch -u fil.org fil.ny > minfiks.patch)
84 - send denne til utvikler-mailinglisten, og følg med om den blir
85 inkludert, eller om den krever mere fiksing.
86 - ikke "glem" en patch. blir den ikke akseptert, sørg for å fikse
87 patchen så den blir akseptert.
88 - "glemte" patcher _vil_ skape merarbeide for deg neste gang
89 programmet skal oppgraderes.
90
91
92 - aktiv prosjektdeltager
93
94 - fiks feilene som er rapportert i bugrapport-systemet (prosjektet
95 _har_ et feilrapportsystem, ikke sant?)
96 - Test og gi tilbakemelding på rapporterte feil.
97 - sørg for at brukerdokumentasjonen er oppdatert, og henvis til
98 denne (så slipper du ekstraarbeide)
99 - sørg for at kildekoden du lager er selvdokumenterende, følger
100 kode-policy og har akkurat nok kommentarer til at formålet med
101 koden er lett å forstå
102
103 - prosjektleder
104
105 <h2>Conclusion</h2>
106
107 <h2>References</h2>
108
109 <h2>Thank you very much</h2>
110
111 <h3>Questions?</h3>
112
113 </body>
114 </html>