Suggest Agenda Items for 24th June 2010 dev chat
Jacob Santos, Alex M., Aaron Jorbin, and 3 others are discussing. Toggle Comments
Planning the next few months, what are the next steps
Review of 3.0 feedback – incoming ticket rate, common issues etc.
It might already be included under “planning,” but we should talk about what’s meant by the proposal that development “take a release cycle off.”
The possibilities seem to be the following:
I vote for #1.
I also hope that it will be #1.
I was thinking that would be covered in planning.
What ever we do we need to spend a couple of meetups probably just talking about what we want to achieve. What to prioritise etc.
I was thinking about this as well. Part of the development is the community and this has always been contributors other than the “core” devs. Most of the stuff I’ve contributed in the past hasn’t been on some planned list nor could it have been most of the time until I made a patch for them.
I think that if I spend the time to write the patch, test it, and do most or all of the leg work that it shouldn’t matter. I don’t want to wait 6 to 8 months for something I want to get in sooner for testing and feedback.
The longer something takes to get into WordPress, the longer it is to get feedback. Truth of the matter is that people don’t really care unless it is in or going into WordPress in terms of testing and the implementation.
As an aside, it did take around 5 to 6 months before the HTTP API went in, but it wasn’t something I was terribly concern on at that time.
Trac and 3.1. — Nacin
3.0.1 and what the backporting philosophy / policy will be (Only blockers/critical or will other bug fixes be allowed in)
For me personally, HTTP API improvements and Rewrite improvements.
This should probably wait until 3.1 development begins, no?
Most of the HTTP API improvements are complete, tested, and awaiting inclusion into core. Rewrite improvements… well, maybe. I think the fact that I don’t like my current code as it stands now says something. I think quite a bit of work needs to be done for the router and controller improvements.
Perhaps, doing it in steps, with 3.1 include the router and have it work with the current Implementation, something that would have little to no implications for WordPress, except make it more awesome. Then with 3.2, move more of WordPress to using the Router / Dispatcher implementation.
Also, if I work on it today and tomorrow, I should have something to show at the meeting. That might be a basis for a discussion other than one I would rather not have, like for example, whether improvements need to be made. I’ve found it is easier to explain and get feedback on code rather than some abstract and, or far off concept.
← We’re skipping the dev chat this week. …
The ability to set “priority” and “mi… →
Subscribe to this blog and receive notifications of new posts by email.
Join 6,539 other subscribers