Classify your RT tickets on CPAN Day!
Last week I encouraged y'all to fix a bug or two on CPAN Day, either in your distributions, or in someone else's. To help you, I listed the top 20 dists by bugs.
David "never satisfied" Golden pointed out that the table would be more useful / interesting if broken down by severity. So here it is. This also reveals that a lot of tickets don't have a severity set, so on CPAN Day we should sort that out too!
Here are the top distributions again, but this time they are listed in order of the total of 'tickets to worry about'. Ie ignoring wishlist and unimportant entries. The total column is still the grand total.
| Critical | Important | Normal | Unimportant | Wishlist | Unknown | Total | |
|---|---|---|---|---|---|---|---|
| CPAN | 7 | 26 | 43 | 24 | 26 | 72 | 198 |
| libwww-perl | 5 | 26 | 35 | 8 | 17 | 73 | 164 |
| Perl-Critic | 1 | 4 | 34 | 7 | 60 | 80 | 186 |
| Tk | 7 | 23 | 15 | 5 | 53 | 103 | |
| YAML | 4 | 21 | 29 | 1 | 8 | 37 | 100 |
| DBD-mysql | 3 | 18 | 16 | 3 | 38 | 78 | |
| GD | 3 | 17 | 18 | 3 | 3 | 36 | 80 |
| Archive-Zip | 6 | 11 | 21 | 6 | 35 | 79 | |
| Math-Pari | 8 | 27 | 9 | 1 | 29 | 74 | |
| SQL-Translator | 3 | 11 | 22 | 2 | 13 | 34 | 85 |
| SVK | 12 | 13 | 16 | 1 | 3 | 24 | 69 |
| App-perlbrew | 4 | 17 | 13 | 2 | 13 | 29 | 78 |
| Storable | 8 | 13 | 14 | 3 | 4 | 26 | 68 |
| IPC-Run | 3 | 16 | 12 | 1 | 3 | 27 | 62 |
| CPANPLUS | 1 | 7 | 13 | 1 | 3 | 36 | 61 |
| XML-Parser | 8 | 16 | 14 | 5 | 3 | 19 | 65 |
| Template-Toolkit | 2 | 13 | 10 | 5 | 6 | 30 | 66 |
| Perl-Dist-Strawberry | 1 | 6 | 3 | 1 | 5 | 45 | 61 |
| IMDB-Film | 2 | 13 | 18 | 4 | 21 | 58 | |
| PPI | 5 | 14 | 4 | 11 | 34 | 68 |
Ugg, it was a pain getting this table to look half-decent.
Thanks to DAGOLDEN for the nudge — it's definitely better broken down this way.
Perl hacker since 1992.
This list could use a little curation. SVK has been long dead. Math-Pari is completely insane, though I guess some people still use it. Personally, I stay far aware and use the GMP bindings instead. As for Tk, I guess people still use it (maybe).
The others would definitely benefit from some bug fixing, though.
Awesome! Thank you. -- David "satisfied for now" Golden
Dave (blog.urth.org): I had no idea what SVK is, but there seems to be consensus that maybe it doesn't belong on this list. And now I've looked, there's no recent activity in RT. I might email the author suggesting he just reject some tickets, and if he's not maintaining it, add a note to that effect in RT (there's a post somewhere about that), and do a deprecated release.
But Tk and Math-Pari both have recent activity, so should probably stay on the list.
I think if everyone classified the Unknowns, we might find that different dists float to the top.
So many yaks ...
First a big thanks for all this blogging. I think it is fantastic that you're doing this!
Math::Pari probably needs a co-maintainer with lots of time. So far I don't think anyone qualified has wanted to step up. It's a lot of work. On the plus side, the RT situation isn't quite so bad -- it would look a lot better with some pruning of duplicates and closing of fixed issues. There are a lot of issues that look like they're fixed but just haven't been closed.
This leads to the digression of how it would be nice to wean the remainder of the Perl crypto modules off of Math::Pari, but they're often in the same boat. The authors are around but don't have time to work on the modules and aren't ready to give them up. There's also the issue of the alternatives: Math::BigInt is core and portable, but super slow for this work without one of the backends, and the backends also have long-standing critical bugs. Math::GMP or Math::GMPz would be the obvious and best choices, but then we're requiring platforms to have GMP installed. I'm still trying to find time to get an alternative out, but it won't be ready in time for CPAN day.
This is, IMO, a problem with a lot of distributions...
Yes, there's a post somewhere about that ("Maintainer's notes on rt.cpan.org").
Would it be an interesting way to engage people's competitiveness in having a separate "RT weekend", so that the score being kept is how many RT (or github, or...) tickets get marked as resolved?