Even though it's cute that my fingers can now type "mailnews/base/prefs/resources/content/accountcreation/" without my needing to think about any part of it, that "resources/" is just pointless. We have exactly one directory named resources that has anything in it other than a single directory named content, and that's just because mime has an abandoned and forgotten pair of .properties files that got copied to locales instead of moved. A bit harsh on patches, but after bug 390262, everybody's all practiced at tracking down where their files went.
I'm wondering if there's a least bad time to land this, e.g., right around a code freeze. It has minimal risk for run-time, right?
Yep, failing to find a file to jar is a build error (as I discovered when I forgot that mail/ still jars smime from mailnews), so your run-time risks are that I got confused and hit ctrl+k instead of backspacing through resources/ in a jar.mn line, so we wouldn't be jarring something, or that I screwed up the destination in one of the Makefile.in changes, or that we have something that fails silently for not found and which isn't indexed by MXR and that I failed when I was grepping to back up MXR's opinions. Or, I guess, that I failed to successfully imagine the reason why we still have those non-localized unjarred copies of localized .properties files, or that Makefile.win :)
Attachment #374575 - Flags: superreview?(bienvenu) → superreview+
Sort of regretting the time I spent writing a script to recreate this patch, since (so far) I've only had to unrot it once.
Attachment #374575 - Attachment is obsolete: true
Whiteboard: [needs a time to land] → [needs landing post-freeze]
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing post-freeze]
Target Milestone: --- → Thunderbird 3.0b4
You need to log in before you can comment on or make changes to this bug.