Edubuntu bugs and you

Jordan Mantha laserjock at
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 [0])
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. [1]

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 [2]. 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
"what's wrong"
  * 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 mailing list