And now for something completely different: iMac G4 versus mini G4 smackdown (plus: who's your Daddy, Carbon API)

The Santa Ana winds were kicking up in Southern California, and I know this because they apparently snarled the phone lines and knocked the T1 off yesterday, which is why Floodgap was down all evening and part of the morning and I haven't gotten much work done on 24.1. Sorry about that.

However, tonight I think I can finally announce I have a working fix for the menu bar freeze in issue 248, which I was able to trigger while writing this very blog post (indeed, it does seem heavy keyboarding is to blame); based on discussion with Steven Michaud at Mozilla (thanks, Steven!!) it looks like it's an operating system bug that we're now triggering more easily, and it's probably happened at least to a limited extent to every previous version of TenFourFox. 10.4 and it looks like 10.5 can get into a situation where it misdelivers events to the wrong control under circumstances I don't yet understand, so it was falsely feeding the mousedown on the menubar to the (invisible) popup window control we use for context menus and click-hold menus, never getting to the menubar. The result is the menubar appears to freeze even though everything else works. This is another case where the Mac's menubar being always at the top of the screen makes things very easy, because catching a click up there should never happen (the OS should have routed it to the menus first), and so interception was straightforward.

I couldn't figure out why that was happening, but I could figure out how to get around it. Analysis of Shark tracing on a working process and a stuck process show they both activate an internal undocumented Carbon API function called _NSHandleCarbonMenuEvent, but it doesn't activate any additional functions in the stuck browser while succeeding in the working browser. Disassembling the Carbon library using otool shows that it takes a single argument (in register r3) which I guessed was a Carbon EventRef. Apple doesn't document Carbon EventRefs and wants programmers to treat them as opaque types, but they do somewhat document older Mac OS EventRecords which still exist in OS X, and _NSHandleCarbonMenuEvent actually calls a documented conversion routine called ConvertEventRefToEventRecord to get an EventRecord that we could spy on. Stepping through it in the debugger, we could confirm that the single argument was indeed an EventRef and the Carbon event kind is stored at byte offset 16 (at least for PowerPC -- I don't know if this is true for x86).

After I was able to trigger the freeze again, I was able to see that the event _NSHandleCarbonMenuEvent was getting was a kind 2 event (a mouseup), not the kind 1 event (mousedown) it should have been receiving. My first thought was to monkeypatch the event type in memory, but since it was already getting the mouseup, we could just inject the orphaned mousedown instead. But how to get the orphaned Cocoa NSEvent our popup window intercepted into the Carbon system menu handler? Using Magic Hat to dump NSEvent, I discovered Apple has an undocumented [NSEvent _eventRef] method in 10.4 for getting the underlying Carbon EventRef (it works with 10.5, too, though 10.5 can just use [NSEvent eventRef]). So, when we get that misdirected event, we use that undocumented Objective-C method to get the EventRef and just feed it back into our undocumented Carbon function _NSHandleCarbonMenuEvent. It seems so simple when I put it that way. Ain't hacking operating systems great?

I don't know if this will work for 10.5, but I can't see any reason why not. We should have test builds up this weekend to make sure it takes care of the problem.

In other news, being a guy with more money than sense (I don't have very much sense at all), I'm expanding my stable of Power Macs. And if you like Power Macs as much as I do, this is the best time to do it. Intel Macs are starting to clog the market in the wake of 10.7/10.8 and people can't even give away Power Macs practically, so prices have plummeted on the used market and I'm stocking up.

My primary machine is still my quad G5, and I use an 12" iBook G4/1.33 on the road (occasionally with an ARM Chromebook with Crouton loaded over ChromeOS). However, the G5 sits in the office in the back of the house, and it's nice to have a second terminal around, so I have a 1GHz iMac G4 out in the commons where I eat and pay bills and such.

I think the iMac G4 is the best looking Power Mac ever made, hands down, better than the Twentieth Anniversary Macintosh which is a real looker (I have a TAM on my bedside table), and the 15" one I have has a perfect arm (not sagging!) and LCD, case and mechanism. But 1GHz is a little poky and a 256K L2 cache is even worse; my iBook G4, which on paper should be 33% faster, is about 50% faster despite having a slower frontside bus because it has double the L2 (Apple has always criminally undercached their designs; see also G5). So when a 1.5GHz G4 Mac mini cropped up on eBay in great shape with 1GB RAM and a 17" Apple Studio Display, I struck and nabbed the set for about $125. But which one is the better Power Mac?

• CPU: No question, the 1.5GHz G4 mini is already faster on clock speed, but also has 512K of L2 and the same 167MHz system bus; easily it's close to 75% faster and maybe more depending on the task. Even the top-end 1.25GHz iMac G4 still has just 256K of cache, so overclocking is of questionable utility; plus, all of the 17" and 20" iMac G4s are starting to show sagging in the arm due to the screen weight. iMac 0, mini 1.

• RAM: The mini is limited to 1GB in one stick. The iMac came with 512MB, 256MB in each slot; I have 1GB in the user-serviceable slot for 1.25GB and I have a stick ready to put in the top. This requires a little bit of disassembly, but the potential is there. iMac 1, mini 1.

• Video: The mini has an 64MB ATI Radeon 9200, while the iMac is still plodding along with a 32MB GeForce4 MX. Plus, 15 inches of screen real estate can be a little confining and using the iMac with an external monitor is heartbreaking. iMac 1, mini 2.

• Expandability: On first blush this looks like a tough call, but after some thought there is a clear winner. Both take relatively standard hard disks and optical drives, and both have 48-bit LBA. Neither machine has PCI slots; both have Ethernet and can come with WiFi, though only the mini offers Bluetooth as a built-in option (as it happens, this one has both WiFi and Bluetooth). Now, you could add WiFi or Bluetooth to either machine, but you need USB ports for that, and that's where the iMac nudges by: it has 3 USB 2.0 ports and two FireWire 400 ports, lots of room for stuff. The mini has only two USB 2.0 and one FW400 port, and one of the USB ports is occupied by the Apple Studio Display controller because the G4 mini doesn't have ADC. You could get around that by getting a different monitor or a hub, of course, but you're still losing a port for the keyboard and mouse, and your cost and inconvenience keeps going up. And, after all that, the G4 iMac has an external video port, too, and can use the Apple Pro Speakers (of which I have several pairs). iMac 2, mini 2.

• Serviceability: The mini is not too hard to work on (once you get over those hideous cracking noises prying open the case), but has a lot of screws to lose, and getting to the optical drive or hard disk can take a little bit of time. On the other hand, the weird form factor of the iMac means you need a lot of workspace and have to protect the LCD and bezel from getting scratched, and if you pull the guts out from the "cone" to get to the hard disk or the second RAM slot you usually need to reapply thermal paste to the heat sink. Neither is unrepairable, but neither is a paragon of repairability either compared with, say, an Outrigger Power Mac or the easy case opening of the Power Mac G3 and G4; call this a wash.

• Hotness: The 17" ASD has a real cool retro vibe, but the iMac G4 is just gorgeous. Pair it with the Pro Speakers and a nice white Pro Keyboard, and it looks great. The arm still supports the screen perfectly. Everyone who comes to my house comments on how nice it looks and how computers in general don't look that good anymore. And that matters. iMac 3, mini 2.

Maybe I'll just put the mini in the bedroom too.

The Cisco Kodec

H.264 has not been the strong suit of Mozilla browsers due to their (until recently) longstanding ban on the codec, and the reason is licensing: MPEG-LA wants money, and they'll sue you if you try to get around them, because the patents are still on the books.

There are various solutions to this problem. In TenFourFox, we have the QuickTime Enabler, which is admittedly clunky and doesn't always work, but because it plays natively in QuickTime Player means it can use its private GPU acceleration capability. On Linux and the *BSDs (great band name), there is GStreamer, and while GStreamer can be coerced into running on OS X, the worry about our using GStreamer's built-in H.264 implementation is that it may violate MPEG-LA's codec patent terms. Since I'm the ringleader, I'd be personally liable if they sent their lawyers over with K-Y jelly and rubber gloves. The way around that, of course, is to use a licensed component that's already on the system; Tobias had done some work on this for GStreamer in AuroraFox, and Mozilla is also doing some, although their approach depends on 10.6 APIs.

Or, have someone pay for the license. Mozilla has consistently refused to allow this option because even though they could probably afford it, their doing so would not grant a license to downstream projects (like us!) who would have to pay their own licensing fees. So a couple of days ago, Cisco said they'd do it because they have a lot invested in WebRTC, the web-based real time communications standard-in-waiting, and they want people to finally standardize on the One Codec To Rule Them All.

Now, before everyone gets excited, while it's still good news, it's not really all that good:

• The only licensed components is the pre-built binary libraries, which are, surprise surprise, not likely to be compatible with PowerPC OS X because Firefox isn't. For that matter, PowerPC Linux isn't on the list of "approved" operating systems either, and you can't just add Cisco's source code to the tree and take advantage of their largesse that way, even though it's open source (it's open source like Android is open source, which is to say, only to the minimum necessary); in RMS unhygienic neckbeard terms, it's gratis, not libre. As a somewhat troubling corollary, Firefox on Tier-1 platforms lacking H.264 support will now go out and grab a binary blob and automatically install it to play H.264 video; it doesn't come with the browser. There'd better be a damn lot of tamper checks on that, and I'll be the first one turning that off on my desktop PC at work.

• Cisco's guarantee doesn't cover the situation that some patent troll crops up and says they've got a piece of the patent outside of the MPEG-LA, and Cisco specifically disclaims their responsibility in that circumstance.

• The license is only for the MPEG-4 video codec. It doesn't cover AAC or MP3 or any other separately-licensed audio codec used for the MPEG-4 audio track, so this wouldn't play most of the videos that are out there by itself (or it would play them without sound). It's for WebRTC, something that we don't support well right now, and WebRTC uses Opus.

So we're not going to do much with this idea, noble as it appears. When IonMonkey is ready and we're sure Australis will work, then we'll work on adding GStreamer support fed through QuickTime so that the only thing we're distributing is the shim to QuickTime (and nothing that runs afoul of the license), and that should take care of the H.264 problem (but QuickTime Enabler will still be supported since it works better on slower systems).

In the meantime, I've stalled 24.1 because the speculative fix I whipped up for issue 248 doesn't fix the problem and I will try to get it out this coming week. Chris suspected a lot of typing causes the menu bar to freeze, and so far, that's the only commonality I've seen on the handful of times I've personally tripped it. If this is happening to you a lot, finding a reliable set of steps to reproduce will go a long way to getting this fixed. 24.2 is coming out, come heck or high water, working fully or no, in December; we're officially out of time.

17.0.10 available, for the last time

17.0.10, the final release of 17, is now available from the Downloads tab (release notes). Use the 17.0.9 changesets to build it. Most everyone should know this by now, but there will be no further releases of 17 barring something cataclysmic between this and 24.2. 17 was a solid ESR. I'm sad to see it go. Assuming no reported issues, it becomes final as usual on Monday evening Pacific time.

Other than the 24 beta and the 22.1 test release, all the beta and test releases have been removed from Google Code to reclaim as much space as possible, but the changesets are still there if you really want them and know the particular rev to check out from the Mozilla Mercurial repositories. Starting with 24.1 beta (hopefully available by the end of next week), downloads will be offered through SourceForge, and Google Code will be offered the finger. Issue tracking and the wiki will remain here for the time being.

Tigers eat Mavericks, don't they?

OS X 10.9 "Mavericks," the first in Apple's new line of non-felid versions of Mac OS X, is now out and that can only mean one thing: I have to update our TenFourFox page layout to mock that instead. :) (The 10.9 spoof layout will come out for 24.0.2 final when we decommission 17.)

Mavericks runs on the same machines 10.8 did, which is to say, no Power Macs, but it is nice that no new machines are left behind. It seems to continue some incremental improvements from 10.8 away from the overly iOSified interface of 10.7 and does not implement the excessive portions of the super flattened iOS 7 aesthetic, but it does not undo some of the irritating interface changes first introduced in 10.7 (scroll bars, ahem), and does not really add much to the underlying operating system other than some truly noteworthy improvements to energy saving. But hey, it's absolutely free. Whaddya want for free?

Instead of a full review -- if you want that, read John Siracusa's typically studious Ars Technica Mavericks analysis -- I think I'll just point out a few things especially relevant to us in the geriatric machine world that most of the 10.9 coverage has missed or not emphasized:

• No one has said what this means for Snow Leopard, and by extension, anyone still having a need to run PowerPC applications or anyone still rocking a 32-bit Intel Mac (or those of us whose token Intel Macs can't run 10.8 and refuse to update to 10.7). I'm presuming nothing good; I was surprised Apple still supported 10.6 with updates after 10.8 came out, and 10.6 is now four years old. Apple has historically not said when support ends for a particular version and it has always been inferred by what doesn't receive updates anymore. The last update as of this writing was in October 2013, consistent with Apple releasing a "final rollup" just before support is dropped in the wake of a new OS release.

• Apple has also declared war on plugins in Safari 7, just as Chrome and Mozilla have. Again, stealing from Siracusa's insanely detailed review, Apple has plugin blocking for both energy and security reasons in 10.9's release. It also shows considerable technical improvement in WebKit2, which because of its greatly improved reliability is now likely to completely eclipse the original WebKit in the very near future, and cannot be good news for Leopard WebKit.

• App Nap, the major power-saving framework in 10.9, is an integral part of Cocoa, and only Cocoa (and only GUI Cocoa apps, at that). Given Apple's increasing emphasis on battery life and power savings, it is eminently possible that this will accelerate the timeframe in which Carbon will be banned entirely from OS X. I would not be surprised if 10.9 is the last version of OS X with any Carbon support, but Apple to my knowledge has not taken the step of banning them from the Mac App Store ... yet.

In port news, IonMonkey PowerPC is evolving, but is not quite up to phase 3 (running simple scripts). It does now get entirely through code generation and optimization after fixing an endian bug in Ion, but I still have to write some of the Ion-specific pieces that I worked around for PPCBC. I'm aiming for a timeframe of 27 or 28, all things remaining equal.

Australis is still a big question mark. On OS X, there remain significant performance regressions, including some 10.6-specific issues. Now that 10.9 is out, this might accelerate Mozilla's desire to drop 10.6 support because we should expect some of the older Snow Leopard-only computers to get replaced (and drop Mozilla's 10.6 user base proportion), particularly if Apple is perceived to withdraw support. This does not mean that Australis can't be ported to 10.4, and because we are entirely software-drawn does not mean that we will have the same performance issues in exactly the same fashion, but it's a little concerning. It doesn't appear that it will be in Firefox 27 either, and there are still a lot of bugs on all the supported OSes.

The beta for TenFourFox 24 has been mercifully well-received, despite the benchmark regression. Most people find it more responsive overall than 17, which is very encouraging. Other than the known problem with Personas and window redrawing, the only other bug that has cropped up is a rare issue with an unresponsive menu bar. The app still works and can be quit and restarted, but the circumstances are not understood; I personally experienced it once, and I have not been able to trip it since. I do not consider this bug a showstopper at this time. I would appreciate anyone who has reliable steps to reproduce.

17.0.10 is building and should be available for testing by Saturday, our final 17 release. 24.0.1 will be released hopefully late next week as the last 24 beta. I am also planning to attack the 26 beta right away.

24.0b1 available, plus gdb7 patch 2

At long last 24.0 beta 1 is available (downloads, release notes). Some technical notes: we now also have new build instructions, and you must use the patchlevel 2 TenFourFox debugger to deal with a problem with debugging symbols. You can get that from the Downloads tab as well. I am hoping that our Tenfourbird friend in the Land of the Rising Sun will be able to make the jump to 24 with us.

So, after months and months and months and months of work (that's almost seven months of work, for those keeping score at home), we are now on PPCBC, the PowerPC-specialized form of BaselineCompiler, and our hardworking methodjit is now released to that great tracing monkey in the sky (though a large part of it lives on in the regular expression library, and some portions are still used by Ion). Was it worth it?

Let's talk about JIT theory. In general, the lower the latency of a just-in-time compiler, the quicker it generates code, but the poorer the quality of the code it generates (no time for significant analysis or optimization). Our first JavaScript JIT, TraceMonkey, was a tracing compiler that had low to medium latency but therefore had low to medium code quality (and because it was a tracing compiler instead of a method compiler, had a tendency to balloon memory usage and get snared compiling code it shouldn't have; much logic was dedicated by Mozilla to avoiding this sort of unnecessary work). Methodjit was a medium-latency compiler. Implemented as JaegerMonkey, it generated code of therefore medium and acceptable quality, but it had a startup penalty which some users complained about during the transition to 10.0. Type inference "JM+TI" improved the code quality, but required even more latency because the interpreter had to run a certain amount of time to generate type information before JM+TI could spit out code optimized to those types (but once it did, the code it generated was pretty efficient, moving the compiler to medium-high latency, but also medium-high quality).

IonMonkey, which we don't yet implement, is a high-latency compiler emitting very optimized code. But its latency comes at a price, particularly on single processors where compilation cannot occur in the background. In fact, Mozilla does not even try to invoke IonMonkey until a particular block of code has run at least 10,000 iterations; it doesn't pay off.

BaselineCompiler (I'll discuss PPCBC in a moment), on the other hand, is a low latency compiler, even lower than TraceMonkey. The browser will attempt to compile code running with as few as 10 iterations (!) in Baseline because there is little penalty to doing so: even though it generates low-quality code, the code that it does generate is over four times faster than the interpreter, and because it generates it so quickly the browser can start executing this code nearly immediately. However, it generates code that is about 60% slower than TraceMonkey, and about 7 times slower than JM+TI.

Because BaselineCompiler cannot make assumptions about the code it runs (methodjit could, because type inference greatly improved its ability to predict at the cost of -- you guessed it -- more latency), it has a dependence on guards to ensure that code that violates its assumptions is properly handled. These guards are an integral part of the inline caches it generates, which are little blobs of code popped out for specific operations as they are run by the JavaScript engine. PowerPC does not do well with branchy code, especially the G5, and because all of our supported CPUs are superscalar we can optimize these commonly emitted type guards with better instruction-level parallelism to reduce branches and improve throughput. That's what PPCBC does, converting these and certain other portions of the inline cache code to PowerPC-optimal straight line sequences, improving our performance on benchmarks by about 15-20% without any penalty to latency. This pulls us to around 40% slower than TraceMonkey, and about 5 times slower than JM+TI.

So by now you should have guessed the tradeoffs, but let's be explicit: virtually all benchmarks suffer. These are long-running sections of code that JM+TI optimized very well, since it had the time to do so. V8 drops on the quad G5 from 2300 to about 450 (but the interpreter clocks in at barely 100). SunSpider time increases by a similar proportion. Because such a large portion of Peacekeeper is predicated on our JavaScript performance, we suffer badly there too. BaselineCompiler also does not utilize the FPU very well, which is really painful on PowerPC because we have no direct ways of converting integer to floating point; benchmarks requiring lots of floating point computation really take it in the shorts, and there is no good way to fix this.

Fortunately, most pages do not have long-running scripts; they have quick-hit scripts, and most of them are using integer or object-based code. This is where PPCBC shines. Pages become significantly more responsive and because we jump into compiled code with a very short delay, there is much less wait. Many, though by no means most, sites fall into this category. YouTube is a site that could go either way, but eBay does very nicely. Gmail feels about the same, but at least it does not regress.

The definitive solution is to implement IonMonkey fully, of course. When fully operational, then after a period of time running, PPCBC-generated code will have accumulated enough type information to allow IonMonkey to emit very nicely optimized sequences, better than JM+TI would have generated for the same input. The good news is that implementing PPCBC first gets us about 2/3rds of the way to Ion since they use most of the same underlying machinery, and it is a predictably performing compiler which is important for our low end systems. (By the way, do not try to enable Ion in the browser. It will crash. You may need to restart it in safe mode to turn this off, so please don't. If you are using the js shell, be sure to start it with the --no-ion option.)

TenFourFox 24 does have better graphics support and improved DOM performance which helps to offset some of this performance loss. We are also using different widget code required by the Australis upgrade, which is improving some of our chrome drawing speed (more about Australis in a moment). I did attempt a build with jemalloc in it, the higher performance allocator that Firefox preferentially uses and that we did attempt an unsuccessful test build with back for the 22.1 release. We scotched it back then for being unable to deal with a memory leak, and jemalloc makes 24 even worse: overnight it ballooned to almost a gigabyte of memory on my quad G5. In addition, the performance delta between regular and jemalloc is much smaller for 24 due to improvements in the core and it only makes a small difference on a subset of sites. So it's not worth the headache now.

The only outstanding bug of significance so far in 24 is a problem with Personas covering up the "traffic light" buttons on redraw (issue 247). It's cosmetic; they repaint when you hover them, and they work normally, so it's just an ugliness that needs to be polished up. This will be fixed for the final release and does not occur with the regular chrome. YMMV, do report as you find them.

Localizers should consider strings frozen for this release, so language packs for 24 can now be created. I am thinking we will have one more beta (24.0.1) to coincide with 17.0.10, and then 24 will replace everything for 24.0.2; langpacks should be ready to go by then. I'll let Chris Trusch comment on the feasibility of that timeframe. Our long-suffering and greatly valued volunteer translators should look for activity in issue 42.

Looking ahead to the future, I am not likely to land Ion on 24 if we can get at least Fx26 running. The reason is simply because I don't know how our systems will deal with it; it's a heavyweight compiler, and it may be too much to be efficient on a G3. We might even only ship it for 7450 and G5, and let G3 and 7400 use Baseline only, which may perform more smoothly on those significantly older machines. However, because PPCBC works fine, Ion is now officially a "solveable" problem given enough time. Evaluating its responsiveness will thus be a big part of the upcoming new unstable branch releases.

What isn't necessarily a solved issue, though, is Australis, the new interface. Some of this code is already in 24, invisibly, and we use some of it for Personas (so fixing the Personas bug is important not because it's cosmetically wacky, but because it's a useful test of code to be used more heavily in a future browser version). However, it still has lots of performance regressions and bugs and it's not even a part of Nightly Firefox builds, just the UX branch; it is now debatable it even makes Firefox 27. Whenever it lands, we need to get Australis working to advance, since almost all of the browser chrome will depend on it; the odds are good as long as 10.6 support doesn't get dropped given our success thus far, but by no means guaranteed.

Anyway, I am relieved that 24 is not an utter disaster. Let me know what you think. I will start working on 26 beta in the very near future as well to kick off our assault on the next ESR, the far-away ESR 31.

And now for something completely different: turn your Mac into a netboot server

Kudos to Martin Kukač, who not only rediscovered this gem, but got the author to release it as freeware: BootMania, a netbooting server that allows any 10.4+ Mac (OS X Server or no) to netboot another. It not only netboots and/or netinstalls OS 9, 10.3, 10.4, OpenDarwin, *BSD and Linux, but it allows you to override the Tiger hardware check and even includes its own DHCP server (just make sure it's not going to freak out your router or other hosts on your network).

It does have one downside, and this is a big one: if you already have a machine you're using for AppleShare, you're going to have to put it on something else; it will not run when the regular OS X AFP server is operating. But, assuming you can work around that limitation (or stop it and start it when you're done), I bet this will resurrect a lot of machines with bad optical drives or the like that just need a little push to get back on their feet. In fact, I have a WallStreet I PowerBook G3 with only a CD-ROM that I think I'm going to try to squeeze Tiger onto this weekend ...

... after I release 24, that is. :) I'm typing this in a test G5 optimized build and it seems to work very well. Although it's not all I hoped it would be, it's not the trainwreck I feared it might become and it's absolutely useable. I'm going to flip it over and build a full set of optimized browsers tonight and throw the lab Macs at them this week. The long nightmare is at last coming to an end.

24.0 gets off the ground

Finally, blogging from within a debugging build of 24.0 after a string of false starts and fixing bugs to get the browser to stabilize. We still fail that lone asm.js test that methodjit also failed, plus an obscure debug-mode-only test which looks like it might possibly be a Mozilla error; neither are causing issues for the regular browser so far. The last remaining crash bug in BaselineCompiler has been fixed, and some other polishing up has been done to make the browser now functional enough to do some larger scale testing. The change to PPCBC has made some things better and some things worse, but mercifully the net performance change is closer to a wash than I had thought. I'll try to give you harder metrics when I have an opt build working and have done more optimization work, and I'd like to see if we can reintroduce jemalloc after I do some testing with its memory consumption.

As I received no objections from the floor, starting with TenFourFox.next (whatever it is after 24), the 10.4 SDK will be the only supported target for linking and the leftover 10.5 SDK code still in the changesets will be gradually purged as it bitrots. Remember, this is only for linking against the SDK. The browser will still run on 10.5, and you can still build it on 10.5, but the only build target will be to make a 10.4-compatible browser. If you want to look at 10.5 specific code, you could look at Tobias' AuroraFox changesets, though quite a lot has changed since then.

If all goes well, you should have a testing beta of 24.0 at long last in a week or two, and then our localizing team will have a full cycle and then some to do translation work which should be hopefully plenty of time for Chris and our gracious volunteers. The plan will be to migrate everyone to 24.0.2 on 10 December as the new stable branch.