[development] Patches - code freeze
dries.buytaert at gmail.com
Wed May 23 07:24:19 UTC 2007
*** Larry wrote in another thread:
> In addition to claiming modules to work on, if there are any
> pending patches that make substantial changes to a core module that
> need to go in before code freeze let us know about those, too, so
> we can not touch that module yet. This performance refactoring can
> stretch post-1 June I believe since there's no API changes (Dries,
> correct me if that's an incorrect statement), and I'd rather not
> block someone else's patch that's almost-there. :-)
There are a lot of patches really, and we could use a hand reviewing
those. And when I say "reviewing", I mean "studying the code and
thinking it through" rather than just showing your support to the
author of the patch. We could use more "in-depth reviews" to help
some of the bigger patches move forward.
I'm currently on the train so I can't check the issue queue, but at
the top of my head (and afraid to miss out on some other important
patches), here is my top-6 things I'd like to see us focus on. In
order of priority:
1. Getting the pending i18n patches into Drupal core -- I'd rather
not ship with a half solution.
2. Getting OpenID into Drupal core.
3. Getting actions into Drupal core.
4. Getting schema API into Drupal core.
5. Paving the path for webservices: data API, being more XML/REST/
JSON friendly, etc.
6. Getting more of CCK into Drupal core.
Most of these patches are important for Drupal's future. If we can't
get them in by the code freeze, this means that these features might
have to wait another year (!) to get into Drupal 7. Having to miss
out on these for one year, might be a really long time ... for
various reasons, I'd rather not see that happen.
At the same time, I'm still looking for patches that help improve the
user experience or that help improve performance. Most users don't
really care about the architectural changes that happen under the
hood; they care about bling and ease-of-use. So things like forum
module improvements, more accessible terminology, tracker
improvements, easier access control, upload/file handling
improvements, search module improvements, are no-brainers that tend
to jump to the top of my TODO/review-list. But when these don't make
it into Drupal 6, they'll be able to live in contrib for a while and
most of the time, that's perfectly fine.
An exception is the update_status.module that Earl and Derek are
working on -- we definitely want that in core even though it is not
an architectural change.
It's not always black and white, but in general, the patches that I
care most about at this point in the release cycle -- and which I
encourage *you* to care most about as well -- are architectural
changes that impact the future of Drupal. Of course, these are more
difficult to grok and review, but when you do, you'll have a bigger
impact on our future. :-)
Dries Buytaert :: http://www.buytaert.net/
More information about the development