[development] Patches - code freeze

[Peter Wolanin]

I would still very much like to get some sort of book module overhall
done, but it really can't start until this patch is in:
http://drupal.org/node/145058  The minimal idea would be to use the
menu code to make the book menu block, which should (I hope) be much
faster than how book module does it now.

Also, I feel like it's a high priority to provide additional help to
Karoly to get menu module to work (at all).

For the code freeze, is it better to try to get new functionality in,
rather than actually doing the work of writing update functions?  Is
it better to leave one core module (menu) broken on the assumption
that later patches will have to go in so that we can refactor book
module?  I feel like I'm in a lose-lose situation.

-Peter




> ---------- Forwarded message ----------
> From: Dries Buytaert <dries.buytaert at gmail.com>
> To: development at drupal.org
> Date: Wed, 23 May 2007 09:24:19 +0200
> Subject: [development] Patches - code freeze
>
> 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/
>
>
>
> --
> [ Drupal development list | http://lists.drupal.org/ ]
>