Re: #ifdefing out mailnews-only code but keeping it in m-c
On 11/12/2013 03:39 AM, Henri Sivonen wrote: On Mon, Nov 11, 2013 at 10:08 PM, Andrew Sutherland asutherl...@asutherland.org wrote: On 11/11/2013 01:33 PM, Joshua Cranmer wrote: Actually, I believe you need to keep the x-imap4-modified-utf7 converters in B2G, if you don't want to break Gaia Email's tests. They use the fakeservers as well, which specifically use this charset. This is minor/easy breakage for us to fix. I wouldn't keep the code around for that reason. Do you mean it's something you'd fix reactively or is there something that needs to be handled proactively before x-imap4-modified-utf7 goes away from B2G? Reactively. It's a small fix but the IMAP fake-server in question is slated to be replaced by the node-based https://github.com/andris9/hoodiecrow in the near/mid-term, and depending on the strategy/timeline for impacting Thunderbird I feel like we might win the race to change over to that. (And we can mitigate failures by pinning our build-runner to a b2g-desktop build that precedes the change for a few days if we can't fix it immediately.) Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: #ifdefing out mailnews-only code but keeping it in m-c
On Mon, Nov 11, 2013 at 6:24 PM, Benjamin Smedberg benja...@smedbergs.us wrote: Why don't we remove them from core and let tbird devs deal with it when they do have time (or stop supporting UTF7 and so forth if it's not important enough to fix)? Removing the IMAP flavor of UTF-7 would break IMAP. I think it would be too hostile to break Thunderbird on that level and to require the Thunderbird developers to drop all other work to firefight such fundamental breakage. As for plain UTF-7 and the other encodings that are on track to becoming dead code in Firefox, if it happens to be the case that some of them are needed for email, it would be bad for Thunderbird if the lack of support slipped under the radar until release and problems only showed up with the wide audience of release builds. It would be less confrontational if a Thunderbird developer stepped up to implement https://bugzilla.mozilla.org/show_bug.cgi?id=937056 without the tree burning first. FWIW, unless I don't understand how this uses the category manager, I doubt that merging would be a problem, and this doesn't sound like a large task for Thunderbird volunteers to take the code we're removing from m-c and port it to c-c. Maybe it isn't a problem. I don't know how the category manager works, so I thought that it could potentially be a problem. By far the easiest solution would be leaving the code in m-c but #ifdefing it out of Firefox builds. Is there a compelling reason not to do so? If there is no compelling reason against #ifdefing it out in m-c, what's the right variable to #ifdef on (needs to work in moz.build and the preprecessor)? I'm not certain whether tbird (and seamonkey) are currently using a shared XULRunner in Linux distros. If they are, then this approach won't work well (we'd at least have to continue disabling these encodings via prefs in Firefox). I don't think that we should be doing the extra pain of ifdefs for this case. What extra pain are you referring to? Sprinkling the #ifdefs around would be as easy as deleting the code from m-c. On Mon, Nov 11, 2013 at 7:14 PM, Gabriele Svelto gsve...@mozilla.com wrote: I did a quick check and found the following: - On Fedora the 'firefox' package depends on 'xulrunner' but not the 'thunderbird' one - Similarly on Debian the 'iceweasel' package depends on 'xulrunner' but no the 'icedove' one - On Gentoo neither the 'firefox' nor the 'thunderbird' package depend on xulrunner as the 'xulrunner' package has been removed entirely I take this to mean that the set of decoders in XULRunner can match the set of decoders in Firefox. On Mon, Nov 11, 2013 at 8:33 PM, Joshua Cranmer pidgeo...@gmail.com wrote: Let me make a few things clear. First, as far as I know, no one cares about UTF-7. That can probably be removed with no harm done to anyone. Someone cared the last time round when UTF-7 was removed from Thunderbird as a side effect of Firefox changes: https://bugzilla.mozilla.org/show_bug.cgi?id=677111 The impact of other charsets are unknown. It is my belief that they could be removed from Thunderbird with little or no wider impact. Unfortunately, I do not have solid data to back this claim up. The reality of Thunderbird development is such that, if this belief does not in fact ring true, we would not find out until the next ESR version is released. The only way to surely get this feedback faster is to add telemetry probes to the current ESR branch and see which encodings are being used. Should one expect release management to allow https://bugzilla.mozilla.org/show_bug.cgi?id=935453 to be uplifted to ESR? (It would be nice to be able to uplift it to Aurora and Beta, too, to get data earlier.) On Mon, Nov 11, 2013 at 10:08 PM, Andrew Sutherland asutherl...@asutherland.org wrote: On 11/11/2013 01:33 PM, Joshua Cranmer wrote: Actually, I believe you need to keep the x-imap4-modified-utf7 converters in B2G, if you don't want to break Gaia Email's tests. They use the fakeservers as well, which specifically use this charset. This is minor/easy breakage for us to fix. I wouldn't keep the code around for that reason. Do you mean it's something you'd fix reactively or is there something that needs to be handled proactively before x-imap4-modified-utf7 goes away from B2G? On Tue, Nov 12, 2013 at 1:57 AM, Mike Hommey m...@glandium.org wrote: Thunderbird is already linking stuff in libxul from c-c. Why wouldn't it be possible to move those bits to c-c and do the same? It would be technically possible, sure. It would be more work than sprinkling #ifdefs in m-c. Maybe not much more work. I haven't done that sort of work before, so I wouldn't know how much extra work compared to #ifdefing it would be without doing the work. -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: #ifdefing out mailnews-only code but keeping it in m-c
Mike Hommey wrote: Thunderbird is already linking stuff in libxul from c-c. Why wouldn't it be possible to move those bits to c-c and do the same? It's compiling components using the internal API and linking them into libxul because originally the mailnews components didn't compile against the external API. (Nowadays it's possible to get Thunderbird-on-xulrunner mostly working; this is handy for contributors on underpowered PCs as it takes much less time to rebuild libmail.) If the stuff consists only of XPCOM components then it would make no difference to Thunderbird whether they were compiled under mailnews or not. I don't know whether the comm-central build system can link non-components into libxul. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
#ifdefing out mailnews-only code but keeping it in m-c
We are building and shipping character encoding converters that are dead code in Firefox but that are used in Thunderbird. Considering the Firefox binary size, it seems like a bad idea to ship to dead code in Firefox. Currently, this includes the encoders and decoders for UTF-7 and the IMAP modified UTF-7. However, as https://bugzilla.mozilla.org/show_bug.cgi?id=863728 and https://bugzilla.mozilla.org/show_bug.cgi?id=805374 get fixed, many more encodings will fall into this category. In principle, the right way to deal with this would be moving code to comm-central. However, this would involve annoyances like setting up a new XPCOM component there and making sure the category manager merges m-c-defined and c-c-defined category entries correctly. Considering the de-emphasis on Thunderbird as far as Mozilla-paid development time goes, it seems unlikely that Thunderbird developers would do the work soon. On the other hand, looking at this as a Gecko developer, getting rid of this code in Firefox builds seems like a legitimate way to use time, but importing the code into comm-central seems less so. By far the easiest solution would be leaving the code in m-c but #ifdefing it out of Firefox builds. Is there a compelling reason not to do so? If there is no compelling reason against #ifdefing it out in m-c, what's the right variable to #ifdef on (needs to work in moz.build and the preprecessor)? -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: #ifdefing out mailnews-only code but keeping it in m-c
On 11/11/2013 10:23 AM, Henri Sivonen wrote: In principle, the right way to deal with this would be moving code to comm-central. However, this would involve annoyances like setting up a new XPCOM component there and making sure the category manager merges m-c-defined and c-c-defined category entries correctly. Considering the de-emphasis on Thunderbird as far as Mozilla-paid development time goes, it seems unlikely that Thunderbird developers would do the work soon. On the other hand, looking at this as a Gecko developer, getting rid of this code in Firefox builds seems like a legitimate way to use time, but importing the code into comm-central seems less so. Why don't we remove them from core and let tbird devs deal with it when they do have time (or stop supporting UTF7 and so forth if it's not important enough to fix)? If these character converters aren't needed as part of the web platform, the projects that do need them should be paying the costs for them. FWIW, unless I don't understand how this uses the category manager, I doubt that merging would be a problem, and this doesn't sound like a large task for Thunderbird volunteers to take the code we're removing from m-c and port it to c-c. By far the easiest solution would be leaving the code in m-c but #ifdefing it out of Firefox builds. Is there a compelling reason not to do so? If there is no compelling reason against #ifdefing it out in m-c, what's the right variable to #ifdef on (needs to work in moz.build and the preprecessor)? I'm not certain whether tbird (and seamonkey) are currently using a shared XULRunner in Linux distros. If they are, then this approach won't work well (we'd at least have to continue disabling these encodings via prefs in Firefox). I don't think that we should be doing the extra pain of ifdefs for this case. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: #ifdefing out mailnews-only code but keeping it in m-c
On 11/11/2013 17:24, Benjamin Smedberg wrote: I'm not certain whether tbird (and seamonkey) are currently using a shared XULRunner in Linux distros. If they are, then this approach won't work well (we'd at least have to continue disabling these encodings via prefs in Firefox). I did a quick check and found the following: - On Fedora the 'firefox' package depends on 'xulrunner' but not the 'thunderbird' one - Similarly on Debian the 'iceweasel' package depends on 'xulrunner' but no the 'icedove' one - On Gentoo neither the 'firefox' nor the 'thunderbird' package depend on xulrunner as the 'xulrunner' package has been removed entirely Gabriele ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: #ifdefing out mailnews-only code but keeping it in m-c
On 11/11/2013 9:23 AM, Henri Sivonen wrote: We are building and shipping character encoding converters that are dead code in Firefox but that are used in Thunderbird. Considering the Firefox binary size, it seems like a bad idea to ship to dead code in Firefox. Currently, this includes the encoders and decoders for UTF-7 and the IMAP modified UTF-7. However, as https://bugzilla.mozilla.org/show_bug.cgi?id=863728 and https://bugzilla.mozilla.org/show_bug.cgi?id=805374 get fixed, many more encodings will fall into this category. Let me make a few things clear. First, as far as I know, no one cares about UTF-7. That can probably be removed with no harm done to anyone. IMAP modified-UTF-7 is used in exactly two places: the IMAP fakeserver and the IMAP protocol. I believe measures were taken several years ago to prevent the use of IMAP modified UTF-7 for use on the web, so it can only really be used by people calling XPCOM charset APIs manually. The impact of other charsets are unknown. It is my belief that they could be removed from Thunderbird with little or no wider impact. Unfortunately, I do not have solid data to back this claim up. The reality of Thunderbird development is such that, if this belief does not in fact ring true, we would not find out until the next ESR version is released. The only way to surely get this feedback faster is to add telemetry probes to the current ESR branch and see which encodings are being used. If I had to make a decision, I would prefer to kill these probably-dead charsets rather than maintain them in comm-central, although both of these options are lower value to me than keep the charsets in mozilla-central such that we could add them back in with a build-time switch if we need to. By far the easiest solution would be leaving the code in m-c but #ifdefing it out of Firefox builds. Is there a compelling reason not to do so? If there is no compelling reason against #ifdefing it out in m-c, what's the right variable to #ifdef on (needs to work in moz.build and the preprecessor)? Actually, I believe you need to keep the x-imap4-modified-utf7 converters in B2G, if you don't want to break Gaia Email's tests. They use the fakeservers as well, which specifically use this charset. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: #ifdefing out mailnews-only code but keeping it in m-c
On 11/11/2013 01:33 PM, Joshua Cranmer wrote: By far the easiest solution would be leaving the code in m-c but #ifdefing it out of Firefox builds. Is there a compelling reason not to do so? If there is no compelling reason against #ifdefing it out in m-c, what's the right variable to #ifdef on (needs to work in moz.build and the preprecessor)? Actually, I believe you need to keep the x-imap4-modified-utf7 converters in B2G, if you don't want to break Gaia Email's tests. They use the fakeservers as well, which specifically use this charset. This is minor/easy breakage for us to fix. I wouldn't keep the code around for that reason. (Character-set-wise, all the Gaia e-mail app wants is for TextEncoder/TextDecoder to conform to the spec.) Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: #ifdefing out mailnews-only code but keeping it in m-c
On Mon, Nov 11, 2013 at 05:23:48PM +0200, Henri Sivonen wrote: We are building and shipping character encoding converters that are dead code in Firefox but that are used in Thunderbird. Considering the Firefox binary size, it seems like a bad idea to ship to dead code in Firefox. Currently, this includes the encoders and decoders for UTF-7 and the IMAP modified UTF-7. However, as https://bugzilla.mozilla.org/show_bug.cgi?id=863728 and https://bugzilla.mozilla.org/show_bug.cgi?id=805374 get fixed, many more encodings will fall into this category. In principle, the right way to deal with this would be moving code to comm-central. However, this would involve annoyances like setting up a new XPCOM component there and making sure the category manager merges m-c-defined and c-c-defined category entries correctly. Considering the de-emphasis on Thunderbird as far as Mozilla-paid development time goes, it seems unlikely that Thunderbird developers would do the work soon. On the other hand, looking at this as a Gecko developer, getting rid of this code in Firefox builds seems like a legitimate way to use time, but importing the code into comm-central seems less so. By far the easiest solution would be leaving the code in m-c but #ifdefing it out of Firefox builds. Is there a compelling reason not to do so? If there is no compelling reason against #ifdefing it out in m-c, what's the right variable to #ifdef on (needs to work in moz.build and the preprecessor)? Thunderbird is already linking stuff in libxul from c-c. Why wouldn't it be possible to move those bits to c-c and do the same? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
