make dash cee, no there is a space,
make space dash cee space, oh
forget it
Becoming a GNOME Contributor
Davyd Madeley
GNOME Applets Maintainer

Overview
What makes a good contributor/maintainer?
●
How I got started
●
How you can get started?
●

Who Am I?
Been using GNU/Linux for some time now
●
Electronic Engineering and Computer Science
●
student at The University of Western Australia
Systems Programmer for a Perth IT company
●
Current GNOME Applets Maintainer
●
one of the newer maintainers, only in my 3rd release
–
cycle

What Makes a Good Maintainer?
What skills does a good software maintainer have?
1) excellent communication skills
2) fluent English
3) good written language skills
4) knowledge of GNOME and its tools
5) project and time management skills
6) software engineering skills
7) knowledge of UNIX build tools
8) programming skills

My First Bug Report
My first GNOME bug report
●
29th of March, 2003
“Galeon uses a lot of CPU when showing dialogs”
I think the issue also appeared in older version (1.1 tree) of
galeon. When a dialog appears, such as login dialog or proxy
authentication dialog, the CPU usage gets very, very high.
Clicking ok/cancel returns it back to normal.
It was a duplicate! :(

Getting More Serious
The first bug I both filed and fixed
●
21st of March, 2003
“netstatus applet refuses to flash”
I'm convinced this is a bug on my end, but I can't work out
where. The netstatus applet refuses to flash, however the
signal strength bar updates nicely. Running gnome­netstatus
from the terminal doesn't show any errors being written out.
/proc/net/dev updates like it should. I had forgotten to compile
GNOME with against libfam (which I've now fixed) restarting
GNOME with libfam capabilities made the wireless strength
part work, but still no flashing lights.

Getting More Serious
After some discussion...
●
Thanks very much Davyd. It took me a while to figure out
*why* we needed the flush on HEAD and not on the
gnome­2­6 branch :­)
2004­03­30 Mark McLoughlin <mark@skynet.ie>
Patch from Davyd Madeley <davyd@ucc.asn.au> in bug
#137895.
● * src/netstatus­sysdeps.c:
(netstatus_sysdeps_read_iface_statistics),
(netstatus_sysdeps_read_iface_wireless_details): flush the
stream's input buffer since we don't read to EOF anymore.

Getting More Serious
March '04
●
Another patch to gnome­netstatus to add IPv6 support
–
still not committed!
●
April '04
●
Submitted a patch to Nautilus, adding the option to hide
–
mounted volumes from the desktop
learnt libraries (and C) as I went
●
Something about improving the Connect to Server
–
dialog
somewhat done nowadays, none of my code involved
●
Drivel
–

The Slippery Slope
The bug that caused all my problems and put me
●
where I am today...
13th of January, 2004 (during linux.conf.au)
“two feature requests for battstat applet”
1) It would be nice if battstat could give the remaining time. KDE's
applet can do this (it calculates it itself I think). From memory
APM gives the remaining time, and you can do a simple division
to calculate it in ACPI.
2) It would also be nice if battstat's warning dialog (for when you
are running out of power) would disappear when it detected the
ACPI event (or whatever is done in APM land) that tells it we
went onto AC power. It would also be nice if the dialog was set
to always on top and sticky, so that you couldn't miss it. Like
with MacOSX, there should still be an option to ok the dialog out
of the way.

The Slippery Slope
From: Davyd Madeley <davyd@madeley.id.au>
To: desktop­devel­list gnome org
Subject: gnome­applets
Date: Tue, 20 Jul 2004 23:00:53 +0800
As far as I can tell, gnome­applets hasn't had a release in the entire
2.7 series.
Who is the current maintainer, is it Kevin V or Kjarten or no one at the
moment?
If no one has the time, I am willing to take up the mantle to at least
get tarballs out for 2.7.4 (*).
­­d
(*) Disclaimer on Offer: I have never done this before, there would be
some fumbling.

So How Can You Contribute to
GNOME?
Most contributors enter the project with a specific
●
problem they want to solve
Having a specific problem allows you to seek specific
–
help
eg. Application X doesn't have feature Y, but I think it
–
should
This is what I did!
–
Not everyone is a good programmer!
●
Perhaps one of the sub projects would be good for you
–
translation, documentation, artwork, bugsquad, etc.
●

So How Can You Contribute to
GNOME?
GNOME Love
●
Lots of new GNOME hackers and contributors, lost in a
–
sea of confusion, undocumented libraries, and C code
Longer­term hackers (“mentors”) who, even if they
–
don't know the answer, know who to ask
mailing list: gnome­love@gnome.org
–
(http://mail.gnome.org/archives/gnome­love/)
IRC channel: #gnome­love on irc.gnome.org
–
Bugsquad
●
Does first level bug triage
–
Marks bugs as incomplete or duplicates, taking load off
–
the maintainers
IRC channel: #bugs on irc.gnome.org
–

So How Can You Contribute to
GNOME?
Translators
●
helps to be a native speaker, or at least very fluent
–
en_AU translation?
–
Website: http://developer.gnome.org/projects/gtp/
–
IRC channel: #gnome­i18n on irc.gnome.org
–
Documenters
●
We Need You!
–
GNOME Documentation is falling behind the desktop
–
due to the rapid pace of development
Writing documentation is easy!
–
Website: http://developer.gnome.org/projects/gdp/
–
IRC channel: #docs on irc.gnome.org
–

Getting Started – Building GNOME
In order to do any development, search for bugs, write
●
documentation or translate, you're going to need a
fairly recent GNOME build.
Two popular GNOME build tools exist:
●
jhbuild – tool for compiling the latest CVS
–
garnome – tool for building the latest released GNOME
–
You don't have to build the whole desktop if you don't
●
want to. Many modules can be built by themselves.
Some distributions (Ubuntu) have refreshingly up to
●
date GNOME packages in their development trees
(currently Breezy).

Getting Started – Development
Tools
Almost anything you do (except bug triage) is
●
likely to end up requiring you to use cvs
Developers like submitted patches to be against
●
the latest version of a particular CVS branch
You can use CVS directly from the source tree
●
checked out by jhbuild
Patches should be generated with cvs diff ­up
●
Patches should then be uploaded to Bugzilla,
●
where they won't get lost

Getting Them to Accept Your Patch
It's all about good communication!
●
... and coding style
If your patch doesn't get accepted, don't give up
●
perhaps consider using the coding style they asked for
–
If you're unsure that a maintainer is going to
●
accept your patch, you can always ask first
it helps to pacify him/her by telling them how great their
–
coding style is
We use GNU coding style!
●

In Summary
Communication makes the Contributor
●
There are bundles of ways to contribute, not just
●
code!
Contribution is easy
●

Would You Like to Know More?
Malcolm Tredinnick is giving a PyGTK tutorial
●
tomorrow
There are heaps of online tutorials if you want
●
them
The Official GNOME 2 Developers Guide
●
Matthias Warkus, No Starch Press
–
#gnome­love
●

Fin ;)
Questions?
http://www.davyd.id.au/articles.shtml
davyd@madeley.id.au