Viewing 3 replies - 1 through 3 (of 3 total)
  • The CVS is replete with notes of thanks to patches submitted by nondevs. If I submit a bug or a patch then ’tis done on my end, what the devs choose to do, or not do, regarding my submittal is their business and is certainly no skin off my nose.

    There are lots of reasons why code that sent in doesn’t get applied immediately. Some patches are applied within minutes of receiving them, while others take months. Generally the bigger the patch, the longer it takes to get in, if at all.
    Every line of code is reviewed by hand. Almost all submitted code I roll in gets partially or wholly rewritten to match our style guides, or be more secure, or more efficient, or to fit in the context of a larger plan. Code that touches the UI undergoes a lot of review and consideration.
    Priorities are important. Sometimes a code change may be blocked by another decision or change that needs to happen first. If a section of code is going to undergo major changes it’s a waste of time to test and incorporate patches for the old code. That’s what happened with the XML-RPC code. Furthermore the XML-RPC is not worked on by myself or Ryan directly, Dougal and Michel handle it so changes in that part of the code happen slower. I forward every patch I get to that code as soon as I get it.
    Owen Winkler wrote some great code for upgrading and installing but I had to refactor a lot of other code before it was worth using it, so it was over a month before anything “happened” in the CVS with his code even though changes leading up that development happened almost every day.
    Code in the forum or list may get lost, that happens. That’s why we have the bug tracker. Once a bug is registered there is no reason to “bump” the bug with comments because it doesn’t change how fast we can get to it. The whole point of having the tracker is to attach state to issues, so if something remains unresolved don’t worry, we know it’s there and it will be addressed before the next release. If a bug is wrongly resolved, then it’s a good time to post a note but all unresolved bugs are treated pretty much equally and triaged according to the stage of the development cycle, what’s being worked on, and developer time.
    Even though a few weeks or a month might seem like a long time remember that our development and testing cycle is much longer than that. Both of these issues were raised after 1.2 is released, and both have been fixed before 1.3 is released. I’m sorry things couldn’t happen faster, but I had to wait almost a year to get some of the stuff I wanted (like nicer permalinks) in.

    What is the best place to submit patches?
    Email – to what address?
    wp-hackers list?
    Mosquito?

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘should non-devs bother submitting patches?’ is closed to new replies.