This was answered on the Testing WordPress Presentation and my response to Mark’s comments.
The first part of Mark’s answer is correct, you don’t want to put enhancements and new features in point releases that usually only have a month before release. You can’t test the enhancement or feature well enough in that time frame to fix all of the issues. Usually what will happen is that a ticket will be posted at a point release and then have to be moved back to trunk milestone.
Also, all fixes will be applied to Trunk first and then back ported to the releases it needs to be. So a developer patching the software needs to not only patch Trunk, but also the previous versions the bug affects. This also includes 2.0.x for security issues and defects that relate to features within the 2.0 branch.
However, the second part is incorrect to a degree. Patches are committed, but only the ones that the core developers care about it seems. I created patches for those tickets that no one seemed to care about and it also seems that the core developers also don’t care about them either, because for some of them, they’ve yet to commit my fixes.
When I stated earlier that I had mix feelings when writing the How to Patch the WordPress Core, it is because I had to almost beg to get patches that I know fixed issues committed to the core. Hell, someone fixed an issue with the PHP 5.1/5.2 default timezone, and it still hasn’t been committed. If it has already been committed since I’ve last looked, it would have taken almost 5 months, before it was committed.
It doesn’t make sense to me that you’ll create a patch for a feature way way before the feature freeze and then when the feature freeze comes, “Oh yeah, feature freeze sending to the next milestone.” Oh yeah, it has a patch, why didn’t you commit it sooner? It makes me really angry and I have trouble caring about creating patches based on the assumption that even if I write a patch, it has a high probability of not being committed without informing the core developers that it exists and have to argue and debate why it should go in.
It is one reason I like the Automattic WordPress Tests, I’ll finally be able to prove that my patch fixes the defect, which will mean that it will push my patches in quicker. At least that is the hope, whether that is the case is up to the core developers.
If you ever woke up, thought about writing a patch for a WordPress ticket, and thought, “What is the point? It probably won’t be committed anyway.” That was me, but I kept with it. If you think about it, there were others that came up to the same barrier of entry, which the core developers blocked and those developers say, “Screw WordPress, I’m going to work on a web application that actually understands the professional paradigms of software development.”
If the intention was always, “Thanks, lets commit this patch right away.” Then perhaps it would be possible that WordPress would already have full inline documentation today.
I think that it is just my level of fixes and what I’m interested in that the core developers either don’t understand enough of the problem to realize that my patch fixes the issue or that they don’t care about my issues enough to actually commit them as quickly as others.
You’re level of happiness in creating patches for WordPress will differ. My level is just about depleted and I almost don’t have any rationalization to continue creating patches. My focus now is inline documentation, writing test cases, and hopefully the Google Summer of Code project, which has a better chance of creating patches that will actually be committed.
After that, I’m done with WordPress, not that WordPress needs me, but if they continue to have their attitude, then they will eventually lose other developers that want to create patches, but also get blocked by the core developers lack of interest in the ticket. I don’t patches to have them just sit there for weeks or months. I create patches for problems I care about and I expect them to be committed as quickly as possible or at the very least provide feedback on why the patch won’t be committed.
If it is said that the patch is unacceptable and why, then that will go a long way with the relationship. I can accept that my code sucks and how I can improve it. I can’t accept not saying anything and just not committing the patch and allowing it to become stale.
The only patches I didn’t have problems with were the patches that added inline documentation, so those are the patches I’m going to create. Alex also seems to commit patches to the Automattic WordPress Tests in a reasonable amount of time, so that is also good. I wish there was a Trac for that or at least a component on the WordPress Trac for archiving patches, tickets and who created the patch.
Possibly Related Posts:
- WordPress Plugin and Theme Scope
- What I’ve Learned From WordPress
- Why Do I Feel Like an Asshole When Criticizing WordPress?
- PHP5 Straw Man Argument
- WordPress 2.7 Changes Class for Plugins
As someone who appreciates your contributions, I hope you won’t let that happiness level get completely depleted, or at least not for this reason.
When the lead devs don’t commit a worthy patch, it seems to me that it’s usually because of a lack of resources. There are I think four commit devs, two of whom rarely commit anything (and then usually just their own work). That leaves basically two people to review and commit everyone else’s patches.
I’ve found that when there’s a ticket I care a lot about, if I bring it up on the #wordpress-dev IRC channel it’s much more likely to be included. That says to me that while there may be larger institutional problems with the commit situation (perhaps Matt should allow more commit devs or the like), it’s not principally an attitude problem but a finite cognizance on the part of the core devs that keeps them from committing good tickets.
It’s funny. The post, “How to Patch the WordPress Core” actually explains some of the reasons why the core developers won’t commit a patch and they are very nice explanations. I didn’t provide the entire picture, but once someone starts writing patches, they’ll likely come up to a roadblock. I came up to a roadblock with one of the first patches I wrote and I’m still working with WordPress. It might be part of the excitement, complaining to get your patch that you know fixes the issue in. When I have nothing else better to do, then I’m all for it, but I don’t like wasting a lot of time proving an issue I know works, because I tested it.
What was really funny to me, was that Mark was answering the question, and I wrote a patch for his ticket. So I mean, he was saying how tickets need to have patches to be committed, but I’m thinking, yeah, even if they have patches they need extra love to be committed. I think it is almost time to add that post to the codex with better explanations on what to do if your ticket is not committed after so long.
In a perfect world, where the core developers have all the time in the world, what Mark said would be reality. The messed up thing to me at least, is that it should be reality.
I’m going to start writing test cases for the Automattic WordPress Tests, which should go through many of the bugs that don’t have a test case at the time and write one up. The people currently working on the Test Suite are doing the same with very high ratio of commits. It is my hope that when I start doing that more, that more of my patches will be accepted. In this way, I agree with you Filosofo, if I can provide proof that my patch fixes the issue, then that will go a long way in to proving my case to have the patch committed.
When one of my patches will be committed after about two or three months, it feels really good, but there is still some lingering anger from it taking two to three months.
I had issues of attitude during the whole translatable plugin metadata debate. I think it was for that reason I almost gave up on working with WordPress. I keep telling myself that I don’t care about localization and that the time it took (about an hour) isn’t worth being mad about. However, every time I think about it, I revert to a five year old and become angry about it, which doesn’t make sense, so I have to slap myself before I write something really stupid. It is pretty wrong to be mad about something that doesn’t matter, that you didn’t care for anyway, and won’t even use if was committed. However, the perceived attitude is something I think I’m a little bit more angry about, which I can’t address without being confrontational about and will probably find out that I was wrong, so I’m an asshole, but I’ll rather not shout to the world about that fact (well, okay it is probably known already).
I’m not a very good debater, nor can I explain myself very well. I was barely able to win one debate, but that was only after the other guy provided the sources that proved my point. It was fascinating, and proving my argument will help me in the workplace, “Why should we do this again?” Because I said so. “Yeah, that isn’t good enough.” Damn.
WordPress, the community, the documentation, and the test suite are too exciting and informational to give up at the moment. I’m less angry now that I had a break from it all and a lot happened in the core that I want to get back up to speed about. There are so many WTF?s in WordPress that one could learn more working with the core in a year than they probably could in three years in school, “You see, this is how you’re not supposed to do it!” Do it this way instead.
I love WordPress as an user. As someone who works with WordPress at work, every defect fix, documentation, and test case helps me to do my job. I only want to worry about my code causing bug defects, not if it is a WordPress defect. If I can help with that in my time, then I’m not going to leave the community until that is finished or we start using another platform at work.
Hey Jacob. I’m the one that suggested the "post stack" plugin over on Weblog tools collection. I am going to get that done for me as I write on about 15 blogs. You commented that it would be ‘cool’.
What would the price be to move that to the top of the pile in your ‘to hobby’ list? I’m not wealthy but if a $100-300 donation to the cause would make you happy, I would gladly pay that for a perfectly working plugin.
I’m not a programmer, but I’m learning from your blog.