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 too. * 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! -Jordan [0] https://bugs.launchpad.net/~edubuntu-bugs/+packagebugs [1] https://wiki.ubuntu.com/Bugs/HowToTriage [2] https://launchpad.net/~edubuntu-bugs -- edubuntu-users mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
