Issues to be resolved before RC [#281934]

This list is for keeping track of the issues that the Panels devs are really trying to see solved before we release RC1. We won't necessarily get to everything on here, but we're going to try our hardest. This issue is intended as a complement to #281829: Patches for worthy issues!, which are basically the issues that we recognize are important, but aren't necessarily prioritizing for RC.

Anyone's free to chime in with a request that a particular issue be addressed, that doesn't guarantee it will be :)

Comments

Comment #1

sdboyer CreditAttribution: sdboyer commented 14 July 2008 at 01:19

I'll keep the current list updated in this very first comment. Remember...this is the countdown to RC1!!!

#230819: Renaming a View breaks panels. (which covers #242038: Renaming views makes panels bork and #279642: views_panes break if you rename source view
#265021: Add minimalistic layout option to onecol layout
#263372: hiding the title causing "Preview" to be displayed instead of nothing.
#148369: Panels in OG homepage overrides $title
#275835: Allow customizing "more" link text
#216194: Add categories to mini panels
#276046: Getting a node thorugh the same taxonomy term from another node - should just be a small new relationship plugin
#263916: Refactor export functions (but #260278: New, consistent save routines will have to come first)
#263372: hiding the title causing "Preview" to be displayed instead of nothing.

Comment #2

sun

German

Karlsruhe

CreditAttribution: sun commented 13 July 2008 at 03:01

I would like to suggest a final code clean-up in front of releasing the first RC. I would be happy to create a patch, but this should happen last, so that patch won't break one of the critical patches.

Comment #3

sdboyer CreditAttribution: sdboyer commented 13 July 2008 at 22:55

I'd actually rather not do the code clean-up before RC is released - I'd rather that be something we do along the way to actual release. Two basic reasons - one, I don't want to delay RC any further, and two, code cleanup can accidentally result in icky new bugs because someone makes a mistake. I'd rather have an RC that we know works, then do code cleanup as we go so that we know we have a good baseline we're working from. If we do the code cleanup before RC, then we won't be able to really know if the problems people come back to us with are the result of changes we intentionally made, or changes that may have unintentionally come about during the code cleanup.