I’m inaugurating a new trac keyword, “bug-hunt”, and the bug hunt report, in order to keep track of of tickets that get posted/could get posted in this blog’s “bug hunt” posts.
Updated: I’m inaugurating a new trac keyword, “featured”, and the featured bugs report, in order to keep track of of tickets that get posted/could get posted in this blog’s “featured bugs” posts.
I’ll be tagging more tickets in due course. You’re most welcome to mark additional tickets as such, if you feel they qualify.
For information, I try to stick to batches of tickets that loosely interfere or interact with one another. The batch of tickets should then meet the two or more of following criteria:
- It is annoying when you run into the issue
- It underscores an architectural problem
- Fixing it can lead to performance optimizations
Areas I plan to highlight in the future include: UUIDs, i18n post slugs, permalinks, rewrite rules, cache, private posts.
Btw, I’d like to stress that the point in these blog posts is try to reverse the WP bug trend:
Open WP bugs, props Hakre
Thus, I’d like to revisit two of my last post’s tickets:
- #10779, on optimizing our unzip method. DD32 committed the fix, but marked it as still needing testing. Here’s how. Related ticket #10403 is still pending, but I feel it’s extremely minor compared to #10779.
- #10913, on optimizing the upgrade process, is still a major niggler imo. #10611 will probably seem cosmetic if #10913 gets fixed. Two possible solutions are highlighted in the ticket’s comments. It still needs a patch, and of course testing once one is around.
We need your help on both, and on future tickets that will make it in these posts. Thanks for patching/testing.
Ryan 6:59 pm on January 23, 2010 Permalink
It would be interesting to see the trend for enhancements/feature requests. Currently, 53% of open tickets are enhancements and feature requests.
hakre 12:30 pm on January 25, 2010 Permalink
Good point.
DD32 10:54 pm on January 23, 2010 Permalink
I’m wondering if ‘bug hunt’ is the correct term for these.
Historically Bug Hunt days are testing a heap of bugs and/or patching them..
The criteria hardly relates to what Bug Hunts used to be (not to speak of them in ast tense, but its been a little while). So i’m wondering if its going to confuse some people, Its not a bug hunt, its just tickets which you see as annoying, or a possible optimization – Many of the latter is not something most people can even attempt to look at.
For a start, #10611 is neither a bug, nor does it have a patch, So whilst it’s a performance thing, Its not something that most people should be told to test..
As for #10779 however, I need to know who its failing for, and what kind of server setup they have.
I’d like to see Bug Hunts left to things that end-users can attack and test, and make sure works for them before being commited (Or testing the commited code still works for them)
Denis de Bernardy 3:44 pm on January 24, 2010 Permalink
Fair enough. Would you find the keyword “featured-bug” more appropriate?
Denis de Bernardy 4:13 pm on January 24, 2010 Permalink
I changed it to “featured”
Jane Wells 2:54 pm on January 25, 2010 Permalink
The word Featured has a lot of connotations in terms of official endorsement and promotion (featured plugins, etc), which we currently already have in trac with the keyword “blessed.” If the point of the tag is that you are asking for the bug to be given a higher priority, a more appropriate tag would be “denis” or “please-look” or something that is more specific.
Andrew Ozz 12:23 pm on January 28, 2010 Permalink
Looking at the chart above: there were a lot of fixed bugs/closed tickets for 2.8 and at the same time it had more problems than either 2.7 or 2.9. So it seems “more tickets closed” equals more problems at release.
Going through the currently open tickets with patches marked as bugs, lots of them introduce some sort of architectural change (no matter how small) which eventually breaks something else. Even tickets marked as “tested, commit” have usually been tested only for the problem described in the current ticket and potentially introduce new bugs.
In that terms I agree with DD32: a “bug hunt” should be a lot less of “patch a bug” and more of “test the patch for a known bug” and leave a comment on the ticket about what was tested and how. Having a list of patches to start with may work but generally most patches need this type of testing.
Matt 6:15 pm on January 28, 2010 Permalink
I am in violent agreement with this comment.
hakre 6:34 pm on January 28, 2010 Permalink
Take note, that the graph does not differ between actual bugs and features as Ryan already correctly pointed to. So Andrew Ozz sentence you violently agree with could be written this way as well:
“So it seems “more features implemented” equals more problems at release.”
Just to show the picture.