Thanks to the work that Anne has done on the Encoding Standard specification and the work that Masatoshi Kimura and I have done to progressively implement the specification in Firefox, we are now at a point where there's a whole bunch of internationalization-related dead code in Firefox. The code is still used by mailnews, though.
I am not done preparing the removal patches yet, but with my current patch queue I can already get 149 KB off of Android ARMv7 optimized apk size and 138 KB off of Android ARMv7 optimized libxul size. (I'm not sure what sort of size wins are considered impressive these days, but at least this is something measurable.) The first three patches in my queue, if landed, would make Thunderbird not work. These patches are UTF-7 removal (https://bugzilla.mozilla.org/show_bug.cgi?id=937056), nsCharsetMenu & charsetOverlay removal (https://bugzilla.mozilla.org/show_bug.cgi?id=943252) and nsCharsetConverterManager & nsCharsetAlias removal (https://bugzilla.mozilla.org/show_bug.cgi?id=943268). The later patches in my queue remove non-Web-exposed encodings, so those won't cause total Thunderbird breakage, but TB devs may still want to import some of the code to c-c. In theory, Gecko engineers are not supposed to use time for tweaking c-c. Yet, just going ahead and totally burning c-c would be terribly impolite and at odds with the notion of Mozilla continuing to keep Thunderbird builds going. That's why I tried to pay attention to the impact on c-c. I've been trying to find a volunteer to make the UTF-7 move since November. I've been unsuccessful, so I reach my timeout and prepared patches myself this week after having obtained managerial OK to put a little time into making c-c not burn. Now I realize that even though I can with reasonable ease move C++ code over to the c-c side, I'm totally unfamiliar with how unit tests and jar manifests work in c-c. I'm worried that if I put time into figuring those out, I'll end up using way more time than is appropriate for Gecko engineer to use on c-c. On the other hand, I'm worried that if I ask c-c developers to figure these things out and wait until they do, I will end up waiting for months, based on what has happened so far, and my m-c patches will rot. So while ultimatums are very impolite, I think there is some need to create a sense of urgency. Would it be reasonable if I created preliminary c-c patches for my c-c-breaking m-c patches so that the c-c patches a C++-wise ready but the unit tests and jar manifests require tweaking by c-c developers and then posted a heads-up about the m-c landing schedule? This way, c-c developers would have a better starting point to unburn c-c, but I wouldn't have to polish the c-c patches to completion and the m-c side wouldn't be waiting on c-c developers indefinitely. I realize that this is still rather impolite from the c-c perspective, but I like to think that I'm still being rather nice in the light of the m-c tree rules and the general attitudes that Gecko developers are supposed to use any time to unburn c-c. Another question: if a c-c patch is ready by the time an m-c patch lands, should the m-c patch land on inbound, in which case c-c developers need to watch out for the inbound merging schedule to see you when they need to land the c-c patch, or should the m-c patch land directly on m-c as an exception to the usual rule of using inbound in order to allow for the c-c patch to be pushed at the same time? -- Henri Sivonen [email protected] https://hsivonen.fi/ _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
