From: Petter Reinholdtsen Date: Thu, 11 Nov 2010 13:07:43 +0000 (+0000) Subject: Dagens foredrag. X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/commitdiff_plain/ee9909d5a00d8d2d00653d7e435ae6a3353a73f1 Dagens foredrag. --- diff --git a/mypapers/free-sw-devel/free-sw-devel3.html b/mypapers/free-sw-devel/free-sw-devel3.html new file mode 100644 index 0000000000..428c887d76 --- /dev/null +++ b/mypapers/free-sw-devel/free-sw-devel3.html @@ -0,0 +1,274 @@ + + + + + + + + + + +

Free software development - community and technology

+ +

An introduction to free software development, for those + interested in participating.

+ +

http://www.hungry.com/~pere/mypapers/free-sw-devel/free-sw-devel3.html

+ +

Petter Reinholdtsen +
pere@hungry.com +
IFI/UiO, 2010-11-11

+ +

Who am I

+ +

been involved in free software development since 1992
programmer and system administrator
past and current contributor to several projects (linux, + glibc, kde, debian-{edu, gis, java, cdd}, mapserver, + openstreetmap.org, skolelinux, etc)
debian developer
initiator and current tech coordinator in skolelinux
currently employed at USIT, UiO

+ +

Free Software - user freedom

+ +

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
freedom to publish modified versions

+ +

Richard M. Stallmann, FSF

+ +

Getting involved and helping out

+ +

So, you found a nice project on + Freshmeat, and want to help + improve it...

+ +

get used to public review +
read the project documentation +
join the relevant mailing list, IRC channels, etc +
use mailing lists +
update the wiki +
get to know the source +
understand licensing issues +
learn to use the bug tracking system (bts) +
start with the non-coding stuff (translations, documentation) +
do not take it personally + +

+ +

Reporting bugs

+ +

This software sucks. A lot!

+ +

test if the bug exist the latest version + +
do not report duplicate bugs, check the bts and mailing + lists + +
document how to reproduce the bug, and include relevant + information. get output from valgrind, strace, gdb and + ltrace. + +
include info on possible workarounds, and patches if you + can.
add more info if the bug is already reported + +
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) + +
remember to follow up your bug report. + +

+ + an + example + +

Submitting patches

+ +

Fixing the problem is only half the work.

+ +

if you can fix the problem you are facing, remember to let + the package author know about this. +
make a patch! (diff -u file.orig file.new > + myfix.diff) +
send the patch to the developer list, or possibly into the + bts (learn how the developers want it) + +
do not forget to follow up the patch. Accept commend and + improve it until it is accepted by the developers. + +
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. + +

+ +

Learn to use the available tools

+ +

There are heaps of useful tools to make the development work + easier and safer as well as to increase the quality.

+ +

Examples include +

version control systems (cvs, svn, git, bzr, etc)
coding environment (emacs, eclipse, etc)
build tools (gcc, jdk, make, autotools, etc)
debugging tools (gdb, ddd, valgrind, etc)
profiling tools (kcachegrind, kprof, etc)
test suite frameworks (dejagnu, junit, etc)

+ +

Starting a free software project

+ +

I got this idea for a piece of software...

+ +

reuse when possible, prefer to improve existing + projects
read other peoples code, download and test other peoples + programs
understand software licenses + +
consider sourceforge + +

+ +

This software suck. A lot! - Do not take it personally.

+ +

Use the best free development tools available

+ +

compile with lots of warnings +
use existing libraries, but avoid to many dependencies + +
learn to use debugging utilities (gdb, ddd, dmalloc, + valgrind, strace, ltrace, electric fence, fncchk, etc) +
learn to use profiling tools (kprof, gprof, etc) +
write automatic self testing + +
do automatic coverage testing to check the quality of the + self test + +

+ +

Running a successful free software project I

+ +

be responsive to comments and suggestions +
write down where you want the project to go +
do not accept every change. make sure you like it first + +
let everyone work on the things that interests them, use the + carrot, as you have no whip +
set up and use a bts + +

+ +

Running a successful free software project II

+ +

create web pages for your project, include screen shots, a + short summary and who to contact for more info + +
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
involve the public mailing lists in the decision making +
automate everything + +
set up system for public review of changes (anonymous CVS, + commit emails) +
communicate the intention behind the choice of license +

+ +

As the project grows larger

+ +

Leading by example is your only option.

+ +

communicate the project plan to all project members +
try to reduce friction and avoid hard language +
keep track of what everyone is working on +

+ +

Conclusion

+ +

working on free software is very rewarding and challenging + +
nobody owns you a favour, get used to it + +
do it for your own gain, not to get rewards from others + +

+ +

References

+ +

"The Practice of Programming" by Kernighan and Pike. + +
"Free / + Open Source Research Community - online papers, + http://opensource.mit.edu/online_paper

+ +

Thank you very much

+ +

Questions?

+ + +