Tag Archives: professionalism

Response to Mark Jaquith’s Answer

Posted by Jacob Santos on April 27, 2008 4 comments

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: