Edubuntu bugs and you

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Edubuntu bugs and you

Bugzilla from laserjock@ubuntu.com
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-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Edubuntu bugs and you

Bruno Coudoin

Hi all,

I just tested GCompris 84.12 as shipped on the latest Ubuntu 9.10 Beta
and did not found any bugs.

The only point I can see is that gnucap is not in the dependency.
GCompris display an error message with a good explanation when you enter
the electricity activity thus it is acceptable. Anyway, if possible I
recommend adding it as a dependency to avoid confusing our users. It may
happen that the person installing GCompris won't use it and won't notice
and the person using it will notice but may not have the knowledge or
the right to install gnucap.

Bruno.


Le dimanche 27 septembre 2009 à 09:49 -0400, Jordan Mantha a écrit :

> 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
>

--
Bruno Coudoin
http://gcompris.net  Free educational software for kids
http://toulibre.org  Logiciel Libre à Toulouse
http://april.org     Promouvoir et défendre le Logiciel Libre


--
edubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-devel