[wp-hackers] We can't and don't rush things into core (was: Long term suckage)

[Mike Schinkel]

On Jun 18, 2010, at 11:06 PM, Andrew Nacin wrote:
> On Fri, Jun 18, 2010 at 6:08 PM, Mike Schinkel
> <mikeschinkel at newclarity.net>wrote:
> 
>> [1] He suggested a simple patch that would introduce a hook that would have
>> allowed me to code my plugin so that it didn't depend on knowledge of the
>> underlying storage of menus but Nacin punted that patch to a future version.
>> So now I have to write my plugin to depend on the knowledge of how menus are
>> stored[3] and it might break in the future. (I'm not 2nd guessing the
>> decision to bypass 3.0 on this specific patch, just using it as the best
>> example of the concern I have.)
>> 
> [1] http://core.trac.wordpress.org/ticket/13694
>> 
> 
> Not in any way related to LTS, but I wish to address this. We have been
> aiming to get 3.0 released for some time, and enhancements were getting
> swift boots. In this case, filosofo linked to a filter added to 3.0 (not a
> patch) which you found sufficient, and then found insufficient. Not that it
> wouldn't enable you to do what you wanted to do, but because you didn't feel
> it was efficient enough.
> 
> These are edge case enhancements that we cannot research and flesh out in
> the matter of minutes, because that's the most amount of time I'd want to
> devote to something like this at such a late stage in the release cycle.
> Hence, I punted it and would do so again.

Sigh. I was explicitly trying not to point fingers at anyone, I even caveated my comments about that patch saying I wasn't 2nd guessing.  

I didn't have a great example so I used the only one I had. I was simply trying to call the question on patch/development priorities. The only types of patches/development that appear to have any significant priority over others are security-related. I was simply trying to suggest we consider some explicit priority for those things that can help plugin and theme authors write more future-looking robust code. That's all.  

More specifically I've run into a lot of concerns about future robustness related to code I've been writing recently because of rough edges in the available APIs but I've been reluctant to discuss the issues here or on trac (especially before 3.0) because I feared my comments might  be taken wrongly, much as my quoted comment above was taken...

I'm just trying to help.

-Mike