On Wed, Mar 14, 2007 at 08:26:55AM +0100, Mike Hommey wrote: > I would like to know, since the release is now very close, if there > could be a final upload of the mozilla-based products.
Note that iceape and xulrunner are currently out of sync between testing and unstable, and I don't see any unblock hints in place for these from the release team. Have unblocks been requested for these? (Sorry, I don't tend to track the status of unblock requests once someone else on the team responds to them.) > I have 2 main concerns: > - A patch (stolen from redhat) that we apply leads to bugs such as > https://bugzilla.mozilla.org/show_bug.cgi?id=370386 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414008 > This is IMHO quite problematic, since it makes the external helper > applications thing more or less useless. This patch, on the other hand, > is also important because it makes helper applications with arguments > work. > We have 3 possibilities to fix the issue: > - backout the patch > - forcing the browser.download.hide_plugins_without_extensions > preference to false > - Apply the new version of the patch, that I sent to > https://bugzilla.mozilla.org/attachment.cgi?id=258000, see the > interdiff with the previous patch, attached. > This applies to iceape, iceweasel and xulrunner. It might be a good > idea to add the patch to icedove as well, if we leave it in the > others. The provided interdiff looks reasonable to me, so I don't object to its inclusion if you believe that's the correct course of action. Is there a description available for the original issue that the redhat patch was intended to solve? (That would help, among other things, with forming an educated opinion on whether it should be added to icedove.) > - Upstream is releasing a regression fix release that fixes the > following issues: > https://bugzilla.mozilla.org/show_bug.cgi?id=370559 > https://bugzilla.mozilla.org/show_bug.cgi?id=371576 > https://bugzilla.mozilla.org/show_bug.cgi?id=373181 > https://bugzilla.mozilla.org/show_bug.cgi?id=371925 > https://bugzilla.mozilla.org/show_bug.cgi?id=370136 > https://bugzilla.mozilla.org/show_bug.cgi?id=371525 At least some of these are security fixes; of course we should have those, but it's also not necessarily the case that they need to get into testing before the release. For others, well, no software is perfect, and at some point it's better for stable to be able to know what bugs we have than to try to fix all the bugs that appear. With that proviso, if there are fixes you think we should have, please go ahead with uploading them; but the longer we have to wait on an upstream release in order to get them, the more likely it is that the release team will judge the risks too high to be included so soon before release. (Sorry, can't be more exact than that without seeing exactly what's going to be uploaded.) > There is a third concern that I forgot: icons. It would be nice if we'd > fix #414012 (and did the same on icedove and iceape) I'm having trouble understanding why this would be "instead of" including icons in /usr/share/pixmaps, as stated in 414012. Wouldn't the intent be to include higher-quality icons in the fd.o directory, with the .xpms currently in /usr/share/pixmaps retained for compatibility with the Debian menu system? Anyway, if a fix is available for this soon enough I can agree that it should be included. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
