[wp-hackers] Bug Rot

[Jacob]

Well, on second thought, this really should be posted to WP-Testers to 
test whether the bugs still exist, but a lot of the bugs need patches.

Going over the bugs, it appears that some of them are for features that 
will probably never become part of WordPress or have been opened for so 
long that it is a wonder if anyone cares.

WordPress 2.4 has 589 opened tickets (at the moment), WordPress 2.5 has 
135, with a total of 724 tickets. There should not be a wonder why some 
people have asked that there be a release of just bug fixes. While it 
would be a good idea, it really should not happen because end users care 
not and would be unmotivated to upgrade for what would seem to be 
trivial. "Come download, this release has over 400 closed tickets."

Over the history, 2.1 closed the most tickets with 469. 2.2 had 240 
tickets, finally 2.3.0 had 351. 2.4 is due in two months and currently 
only has 89 tickets closed. It might be possible, but since most of the 
bugs are of general and administration nature, it might be safe to say 
that with the new administration theme/panel some of the bugs might be 
able to be closed out. Then again perhaps not.

The point I'm trying to make, is if a bug is open for over 6 months 
without any traction, what does this mean? As the unit tests grow and 
documentation improves, it can be safe to say that a lot of the bugs 
will be found and smashed before it gets out there in the wild. However, 
with any new code (taxonomy, improvements to plugin api), there are 
bound to be obscure issues that will come up only through manual 
testing, and even then it might be difficult to reproduce those bugs. 
The problem then is how do you know you are reproducing it correctly? 
Should I go with what I see and decide it isn't an issue and wait for 
the reporter to reopen?

Ah, but it might be a while before the entirely of WordPress is Unit 
Tested, how many people care? If you love to code, then unit testing 
would be heaven. Think about it. What more fun can you get out of coding 
than writing code that tests code! Eh. I fall victim myself, should I 
write unit tests or no? Well, WordPress doesn't require it and it is 
really adds about 20 to an hour more. Plus, hell what if you find a 
mistake, you have to go back and fix your code and who wants all that 
trouble?

It would be nice if every bug had a patch, but looking through the bugs, 
not many of them are sexy. XML-RPC, no thank you, I choose torture 
instead. Plus, have you seen the library? No way I'm touching that, it 
looks sexy, but XML-RPC is way over my head. Alternatives are PHP 5 
only, so unlikely to be accepted by the powers that be.

In any event, it completely sucks to spend the time to write a patch and 
then have it rejected. I would very much rather not use Globals, but 
Registry Pattern. Andy (I apologize for the asshole-ness of my sarcastic 
response, I failed to realize the context of what you meant with 
"April"... I'm a dumbass), if the goal is to not use globals but a layer 
in between, then I'm all for it, hell I would totally help write that 
code in a heartbeat. It is sexy, the Registry Pattern I mean, and sexy 
like Unit Testing. What would make it even better, is if the API was 
developed using TDD!

While having a registry pattern API might help in CMS development, the 
additional layer between your variables and your code would add 
additional overhead. I understand why others wouldn't want it, 
additional complexity, additional overhead, additional work between 
variables and your code, and lack of language support (nothing quite 
beats <?php global $var_name; ?>. However, if you think about some of 
the variable names that WordPress uses, it can be easy to think how when 
other programs are introduced, how one of those programs might also use 
one of those generic termed variables.

I'll stop there. What I mean to say is that, with some of the tickets 
are feature requests that either have no work associated with them or 
work that will never be accepted. So either you run the risk of 
producing a ticket that might be extremely useful and have the author 
become uninterested with supplying a patch, or you have an idea with a 
patch that no one (except a (few) minor player(s) that don't matter 
anyway, re: no commit access and those people's opinion don't matter. 
Sad but true.)

That is entirely frustrating, because my time is valuable and I very 
much hate for my time to be wasted. Not valuable in the sense that I'm 
paid a lot for being a programmer (I'm not, but I'm more happy to have 
the title of "Web Developer" than making money), but valuable in that I 
have to choose between one project or the other. If I choose one 
project, then I can't do the other project. So I mean, I might have to 
apologize to Travis too, because that guy is right very often too.

In that case, it makes sense that you'll want the community to be nice 
to each other. Even through, I don't matter, if I make it not fun for 
another person, then that other person is unlikely to create a patch and 
provide a very good solution. That would be a shame, if not from the 
perspective of the user who enjoys improved stability, then for the 
missed opportunity to learn from another. The most important thing is to 
learn and one of the most enjoyable part of the WordPress community are 
the intelligent programmers and how much I've learned from the patches 
and those that wrote WordPress documentation.

Yeah, it would be nice if some of the older tickets had more recent 
relevance to them.

-- 

Jacob Santos

http://www.santosj.name - blog
http://wordpress.svn.dragonu.net/unittest/ - unofficial WP unit test suite.

Also known as darkdragon and santosj on WP trac.