Edubuntu bugs and you
laserjock at ubuntu.com
Sun Sep 27 14:49:19 BST 2009
With the release of Edubuntu 9.10 coming closer every day I would like
to throw out a relatively simple way people can be helping make
Edubuntu better: working in the bug tracker. First of all, this
doesn't mean fixing bugs and coding (although that's always wonderful
too). What Edubuntu actually needs is people who can spend a little
time working in our bug tracker (on Launchpad, the best view is )
verifying bug reports, getting enough information from bug reports for
developers to take action, and forwarding software bugs to the
"upstream" authors. Even finding and merging duplicate reports is a
great help. The Ubuntu Bugsquad had written some great documentation
on how to get this done. 
It is significantly easier to get bugs fixed prior to the final
release than trying to get things fixed in -updates, so if you want to
make sure Edubuntu is working for you, please consider doing yourself
and others a favor and spend a few minutes working on the bug tracker.
Even an hour here or there on an evening or weekend would make a big
difference. If you're interested in taking it to the next level,
consider joining the Edubuntu Bugsquad . You then will receive all
the emails from bug reports on Edubuntu packages and many thanks from
Edubuntu developers and users.
We currently have 290 listed open bugs. I would love to see this < 100
in the coming months, especially as we work our way to Edubuntu 10.04
which will be a Long Term Support release. Here is the list of
packages that have ten or more open bugs right now:
* edubuntu-meta (11) - I'm going to start "triaging" these today
* gcompris (11) - Debian and upstream developers are generally
responsive and helpful, we should be able to squash these
* gpaint (12) - tends to be somewhat buggy, not sure what the
upstream status is. It would be good to have a comprehensive list of
* kdeedu (17) - a flagship Edu suite. A number of bugs could be from
KDE 3 -> KDE4 transition. Upstream is great to work with, no reason we
can't squash a lot of these. Kubuntu developers are a great resource
* kino (20) - similar to gpaint
* ltsp (80) - critical package and has the most bug reports
currently. We have a dedicated maintainer (Stephane Graber) but he
definitely needs as many hands as possible wading through these bugs.
* moodle (20) - traditionally a fairly difficult package. We could
really use some testers to verify these bugs.
* screem (25) - ditto from kino and gpaint
* scribus (14) - number of crashers and unverified bug reports. This
should be a fairly good place to start.
* tuxpaint (11) - upstream is pretty good about getting fixes, we
need to verify bugs still exist and forward the rest
These packages account for 3/4 of Edubuntu's bugs. If we squashed even
half of them we'd have 1/3 less bug reports!
More information about the edubuntu-users