You are here: Home > Mozilla

Mozilla

Thursday 13 July 2006

  • The endtimes patch for Tinderbox has landed - Over in bug 334592, justdave and morgamic were to address the patchy nature of the tinderbox.mozilla.org install. The bug had slipped by me when it was originally filed and I discovered it only a couple of weeks ago. Based on LOC I'm the biggest transgressor, so last week I finished up (or at least pushed along) the project I started last year of updating the Tinderbox waterfall display for accuracy's sake. I tossed the current Tinderbox install into my brushed nickel patch collander and out came 10 patches, each now attached to the bug. The biggest of these was my "new fangled display/endtimes" patch which cls and bear have already got checked into Tinderbox's CVS home. Doing the original work in June 2005 took much effort and it's great to see that work through so others can have access to this code for their Tinderbox installs.... (12:12)

Thursday 30 March 2006

  • The 2nd National Summit for CWNs - The Second National Summit for Community Wireless Networks will be held this weekend in St. Charles, Missouri and I'll be speaking during the Open Source Wireless session. If you're suitably interested and in the area over the weekend, check it out!... (22:42)

Sunday 26 March 2006

  • ISO The Mozilla Project's Identity - At the Firefox Summit in December 2005 during the Mozilla Project Dynamics talk, Mitchell posed the question of what concerns we had as changes occurred within the Mozilla ecosystem. The concern I mentioned was that as the changes happened, we may forget who we were. It was a concern of an identity crisis. But as I vocalized my concern, I realized (and spoke) that I wasn't sure the community was even conscious of its own identity. Those present nodded in agreement. How could this problem come about? I don't believe it's the result of anyone's miscalculation. It likely stems from an informal group dynamic. The project is open source. One can get at the code without signing documents, or agreeing to the project's mission. The project is what people make of it. When people become a part of the community, prove themselves, and move into positions of responsibility throughout the project, no one's required to state an oath to selected principles. The "shared knowledge" in our community is a common phenomenon among projects of all sizes. But as we've grown from small to large, shared knowledge that's not written down has become a detriment. These are a few things that lead to a big problem: No one knows why the other is here. So what unites us? Are we united by a cool app? By many cool apps or the prospect of a cool app? Are we united by purpose of freedom? By community? Are we here for what could come? Is the process part of the reward? Or do we exist in a vacuum of values, where utility derived from the code is irrelevant to our communal interactions? We are a bohemian collective of tech rebels and stalwarts. Sometimes we are our own producers and our own consumers. We are for our users. We are for open source projects. We are strong and unsure. Weak and wise. We provide a means for others' expression (such as Flickr, IBM, and Google on the web and with email). We can be method without soul, or soul without expression. Can we simply be what we choose to be? What do you think Mozilla is all about? I welcome you to offer your views for what you see as the Mozilla project's identity in comments below.... (17:46 | 4 Comments)

Wednesday 1 February 2006

  • Resignation - Tuesday, February 7, 2006 will be my last day as an employee of the Mozilla Corporation. I joined the Mozilla Foundation pre-Firefox 1.0 (but not too pre-) and, closer to the end, I was given to the Corporation. Unfortunately, the Corporation and I drifted apart, and one or both of us wasn't strong enough to find each other again before it was too late. The Foundation was a unique personal and communal experience. I miss those high days of deciphering and discovering the Project, from top to bottom, from outside in. The Foundation gave me reign to dig into Mozilla and discover its onion-like layers. Any time I was stuck in a layer, I could peel it back and learn a new one. Those days faded. In the Corporation I had lots of day-to-day responsibility and little knowledge of where the place as a whole was headed. Somehow, while changing in other obvious ways (new hires, new structure, new offices), the Corporation became much more opaque than the Foundation had ever been. Difficulty From inside, the Mozilla Corporation is opaque and difficult to understand. This is hard to admit because workplaces don't become opaque without failures at multiple points. There needs to be at once activity and structural changes in the organization, and people need to either be so busy with their own work or, if they notice that it has become difficult to understand what's going on, not ask why. I fit into at least the former category and possibly the latter. I was conscious of the opacity's extremity as a problem only later. Had I noticed it earlier, I could have asked questions. But I didn't. It was either: Finish the release that was months behind schedule and driven internally as required for the organization to stay relevant. or: Make it my mission to figure out where we were headed or at least what it was we wanted to do. False dichotomy? I don't think so, but I'll entertain the possibility. Regardless, either of these paths is a full-time job on their own. Possessing engineering tendencies, the first path was the obvious choice. In hindsight I should have chosen the second path, wading deep into the management layer to again decipher which direction we were pointed in. Again? Each time I had burned myself out working for Mozilla, I would disconnect for a week or two, recharge, and come back to understand where we were headed so I could help with the next big thing. I understood by watching people interact, by attending meetings, and by paying attention to the organization as a whole. The entire cycle usually lasted around 2 to 3 months. Here's what it looked like: Activity Frame of Mind Time spent Find hard+relevant problem no one has the time to tackle on their own Recuperation/Tinkering 2 weeks Generate solutions, figure out all who's needed to solve problem Recuperation/Furious Hacking 3 weeks Recruit people to join in fixing, fix problem 1-4 weeks Verify fixes Furious... (17:21 | 15 Comments)

Wednesday 11 January 2006

  • Thunderbird 1.5 released; Thanks to Scott and David! - Thunderbird 1.5 was released today! Thanks to Scott MacGregor and David Bienvenu for their work from start to finish on Thunderbird 1.5. They put lots of time into this release, maneuvering on top of a mostly-stable Gecko 1.8 foundation and expanding Thunderbird's featureset at the same time. It means a lot that there are people out there bettering the client side user experience for email. Kudos Scott and David. -- a proud Thunderbird user... (19:13)

Thursday 13 October 2005

  • Call for Help: Linux Profiled Builds - The Soft Sell Thanks to Brian Ryner's heroics back in the day, we are capable of building and distributing Linux profiled packages for Firefox 1.0.x. Now that we've moved on to new build systems, new operating systems, and new toolchains, replicating that profiled build process onto the new systems took a back seat to other issues. We'd love to have a cookbook for adding profiled build capabilities to a new build system. In honor of our desire to build them again, I filed bug 292377. Aspiring developers or long-term Mozilla hackers alike, please take a look at the bug and let us know if and how you can replicate a good toolchain for building profiled packages on a modern day Linux OS. The Hard Sell Are you a Linux die-hard capable of toolchain-irifics? Do you help yourself fall to sleep by counting compiler flags and then dream of mozconfig settings? While it's too late to switch to Linux profiled builds in the 1.5 cycle we could add the changes to our trunk nightlies and ensure we have them in place for our next major release. Maybe you can help us scratch the community's itch by generating that exact recipe of what tools need to be installed and what mozconfig settings are needed on late-day Linux systems to bring Linux profiled builds to the masses? Take troubleshooting bug 292377 for a spin and if you answer the $64,000 question[1] you can brag to your long-haired Linux sysadmin friends that you helped us bring back profiled builds. [1] No, this isn't worth $64,000. But if you do it, I'll buy you a beer the next time you and I are at Molly Magee's.... (19:24 | 2 Comments)

Friday 7 October 2005

  • Firefox 1.5 Beta1 to Beta2 Update is Live! - After jumping over numerous hurdles (viz. uncovering some unexpected bugs, sorting fixes, turning water into wine) we've now got the Firefox 1.5b1 to Firefox 1.5b2 update live for download! If you're running Firefox 1.5b1 you should see the update notification sometime over the next couple of days. It will be easy to try out because the partial patches from 1.5b1 to 1.5b2 for each platform are around a megabyte in size! :) As this is the first release we are issuing an update for using the new system, we anticipate things will be smoother going forward. Here are the bugs we know about already: 306170 - background download fails if server returns 200 response 311613 - UI doesn't update when going from partial-> full update 311614 - Partial Update Window should appear in front of browser, not behind Please file new bugs under the Firefox product and select the "Software Update" component. Thanks!... (20:13 | 6 Comments)

Monday 26 September 2005

  • Build system downtime: 9/26 - 9/29 - Some of our Tinderbox build systems will have downtime over the next 2-3 days as we move them from our old office to our new space. Mostly this will affect SeaMonkey-Ports and a few branch/trunk systems. The main Firefox, Thunderbird, and SeaMonkey build systems will not be disrupted.... (11:55)

Wednesday 21 September 2005

Sunday 11 September 2005

  • Nano Nano - I've owned a Rio Karma since November of 2002. It's worked well enough for me everyday since then. It's been with me through SuperComputing (2002, 2003), through NEES (2002-2004), Globus (2002-present... hi WFG). Champaign, Urbana, Mount Vernon, New Orleans, New York, San Diego, Phoenix, and my move from the Midwest to the Bay Area. But lately I've been despondent. You see, Rio's just gone out of business. It's sold all of its DAP assets to other companies and exited the field. For the past two years UKRE (UK Rio Engineers) have held out hope that the next-gen Karma will be just around the bend. Codenamed 'Chroma', it was supposed to do everything the Karma did but with a flash memory slot, a color screen, a bigger hard drive, and better media format support. And I've held up my end of the bargain. I was a loyal Karma owner. I dutifully reset it whenever the player hung. I defended it in forum posts and even tried to assist in debugging it. I waited for the Chroma. And I waited. And I waited. And it never came. Meanwhile, I got back into NPR, PRI, and KQED. Then I found out these stations offered podcasts of their shows. I found out that not only did iTunes handle podcasts but that iTunes handled podcasts beautifully. I didn't have to think about it. Then, on an innocent-looking day, Apple released the iPod nano. The iPod is okay. It does playback of MP3s with iTunes integration. But it doesn't support gapless MP3 playback. It doesn't have a built-in radio tuner. On the other hand, it's where the biggest mover in this field is at. It's what everyone has bought into. So I did, too. I named my new iPod nano nanite. It's got a day or two worth of public radio podcasts stored on it already. It has photos of my family, friends, and trips. And I like it. Actually, I don't just like it -- I RIP Rio. It's nano nano for me from here on out.... (22:16 | 4 Comments)

Thursday 1 September 2005

Saturday 27 August 2005

  • Mozilla 1.8 branch Mac l10n builds now available - Firefox and Thunderbird l10n builds on Mac from the Mozilla 1.8 branch are now available to download: Firefox Thunderbird Thanks to Mark Mentovai for sticking in there to track down the obscure Mac static buffers problem which was leading to the build process being corrupted, along with the EULA work.. Mark, next time you're in town, a round is on me.... (14:20)
  • Proposal: An extension for managing software update channels - With the landing of the software update channel patches a whole new area of functionality in software update has been opened up to Firefox and Thunderbird. But for the user, the system has a big gotcha.. they can't go to about:config and change app.update.channel -- changing the channel requires editing a file within an installation. Why? By keeping the channel data out of the profile (where about:config stores user-overrides) we allow each installation to be on different channels. How are channels being used right now? Our nightly builds are produced with the nightly channel so when they check in with AUS2 they get the next nightly build. When a developer builds Firefox or Thunderbird by default their build will use the default channel so when that build checks AUS2 the server will tell them there are no updates. (No more improperly updating hand-built debug installations to optimized installations!) How will channels be used in the future? There will be a beta channel which will allow those who download beta releases to update only to later betas, RCs, and final releases. There will be a release channel so that users of 1.5 will only get updates to 1.5.1, 1.5.2, and so on. But, will we desire that users ever change update channels in an installation? Or, will users need or want to change the channel for their installation? We aren't sure the answers to these questions, but in case the answer is ever "Yes" it'll take some work on the user's part to change that channel. They must go to their installation folder, enter the default/prefs/ directory, and edit the file channel-prefs.js by hand. So, to the extension wizards out there, here's a challenge: can you produce an extension which provides a simple, elegant user-interface to change the software update channel for an installation? Something that offers testers the ability to try out alpha or beta releases and to keep moving forward with our daily builds as they gain quality -- or in some cases, with newer features but also with the caveat that they could be less stable. If you're interested in giving it a shot, let me know: my email address is chase@mozilla.org. I'll work with you to help test your extension or give you feedback along the way about how we might want to use the channel system down the road.... (14:01 | 3 Comments)

Wednesday 24 August 2005

  • Software update channel patches are in! - Earlier this evening I landed the patches in bug 302721. This work is the result of much effort by the software update team -- Darin Fisher, Ben Goodger, Mike Morgan, and myself with reviews and additional patches by Scott MacGregor, Brian Ryner, and Benjamin Smedberg. It adds the capability for Firefox and Thunderbird to send channel data along with the rest of the app's information to AUS, the Application Update Server. What channels will we eventually have? Time will tell. For now, AUS recognizes two channels: default and nightly. When a build is created and --enable-update-channel isn't set in mozconfig the 'default' channel is selected. The trunk and Mozilla 1.8 release build systems all embed the 'nightly' channel. The default channel gets no updates from AUS while the nightly channel gets the latest nightly build. Firefox 1.5 beta will be released with a channel that will let AUS limit the updates downloaders of those builds get to beta quality or better through the 1.5 cycle. In case you want to disable software update for a nightly build that you've downloaded, follow these steps: Go to Tools → Options. Click Advanced. Click the Update tab. Under "When updates to Deer Park are found" click "Ask me what I want to do". However, we encourage nightly users to help us test software update as we drive towards the beta. Feedback is welcome and if you're interested in providing more data or hearing our software update testing plans, please join the software update beta testing mailing list.... (22:58 | 5 Comments)

Sunday 21 August 2005

  • Software update on the trunk and Mozilla 1.8 branch - Thanks to Mike Morgan, late last week AUS2 (our next-generation Application Update Service) now handles updating trunk and Mozilla 1.8 branch builds. Also required was the feeding of AUS2 information about 1.8 branch builds from the Tinderbox systems. As of today both Firefox and Thunderbird installs on the 3 tier 1 platforms that are using the update test URL should be able to update, conforming to expectations. Assuming you're using that update test URL, if you install a Firefox or Thunderbird trunk build, over the next day or two you should get an update to the latest trunk build for that product and platform. If you install a Firefox or Thunderbird Mozilla 1.8 branch build and use the update test URL, over the next day or two you should get an update to the latest Mozilla 1.8 branch build. The next step is to land channel functionality, then turn on nightly update by default on a temporary basis. Want to find out when our testing begins on a bigger scale? Head over to the QA blog to get info on how to sign-up for the software update beta testing mailing list.... (16:54 | 2 Comments)

Friday 12 August 2005

Wednesday 10 August 2005

  • Seeing the build forest for the build trees - We're still getting ready for branching Mozilla 1.8. Part of that prep work is tuning our build systems to build code from the branch. These past two days I've spent putting together the Mozilla1.8 and Mozilla1.8-l10n* build trees. http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8 http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8-l10n These systems are doing trunk builds until the branch is created. The main configuration details are in-place: they upload to latest-mozilla1.8, they report with special names based on what they're building, etc. When we branch we'll be busy shifting these builds to grab code from the branch so that we have immediate build coverage.... (18:06)

Tuesday 26 July 2005

  • Making Old Tinderbox Data Easier to Retrieve - Today I hacked in a new feature to the Tinderbox server scripts which makes viewing build data from the previous 1, 4, 12, or 52 weeks easier. Links to this data can be found just under the "Show previous 24 hours" text near the bottom of the Tinderbox page.... (13:37)

Tuesday 14 June 2005

  • Build infrastructure in-place for trunk localizations - Last week I finished fine-tuning the localization (l10n) build systems to get Fx-Trunk and Tb-Trunk building on Windows, Mac, and Linux as expected. Now that the build infrastructure is in-place for nightly trunk l10n builds on these platforms, most of the remaining work will be happening in the mozilla/ and l10n/ modules themselves. If you'd like to watch what goes into the process of enabling from-CVS nightly builds and releases for 30+ localizations of world-class products like Firefox and Thunderbird, the following links will be helpful. Firefox nightly builds build status Thunderbird tracking bug nightly builds build status... (12:31 | 1 Comments)

Tuesday 7 June 2005

  • Software update's bright future - Darin and Ben have been working hard on a revised software update user experience and, now, a decent chunk of that initial work has landed on the trunk. Darin has a great demo he's been showing of the client downloading updates in the background and applying them after a restart. Ben has a screenshot of the GUI for one scenario that could happen during update. The plan right now is to bang out the larger issues currently facing the code, address build system work to create the complete update packages of nightly builds, focus on server work to create the update data the clients request (telling them whether or not an update exists), then turn our attention to creating a process for making partial updates based on previous builds. It's our intention to have an initial take on most of this work completed as a part of the Deer Park Alpha 2 milestone. Bettering software update is a "must ship" deliverable for Deer Park and the strides Ben, Darin, and company have made prove it.... (18:10 | 5 Comments)

Monday 6 June 2005

  • Making the Talkback client build more robust against server failure - Over the last couple of months we've run into our fair share of issues with the Talkback client not being included in various builds. Whenever the Talkback servers hiccupped, build systems would feel that pain. While keeping the Talkback servers in steady shape is an on-going effort (Jay, our Talkback expert, can attest), the Talkback client going missing from these builds was an ugly side-effect which would bite us at any time -- whether during a nightly release build or a release respin. The result being that we would need to respin the affected builds again, delaying everyone's work further. Peering into the mysteries of the Talkback server some time ago, we found we could cut the servers out of the loop and generate the necessary parts for the Talkback client without any server interaction at all. The main thing holding us back was that we had no time to implement and test the changes. Last week offered an opportune time to make such a big change to the build process, having just completed our release of Firefox and Thunderbird 1.1a1. As of noon last Saturday, all release builds including the Talkback client that are built from the trunk, the Mozilla 1.7 branch, and the Aviary 1.0 and 1.0.1 branches no longer require interacting with the Talkback server to build the client. While the client build can break and has broken before for other reasons (eg, API changes in the core Mozilla code), the most common cause of the client breakage in our nightly builds has now been resolved. I flipped the switch on this but couldn't have done it without Shiva T. and Jay. Thanks to Shiva for his pointers on what to look out for when generating the master.ini templates and Jay for his verification work that the Talkback client still functions as expected after the changes were made.... (17:13 | 3 Comments)

Sunday 5 June 2005

  • Experimental Tinderbox - I've gotten favourable responses on what I've labelled Tinderbox's experimental version. Enough so that I've decided to push forward on getting my changes into the main scripts. The first step: complete the work I started on the experimental view. I finished that up tonight while Firefly played in the background. Next step: clean up and modularize the changes. Shiny.... (02:38 | 10 Comments)

Tuesday 31 May 2005

  • XTech the Lunchbox - I'm still jetlagged from the Amsterdam trip (given I never recovered while in Amsterdam). Later I'll write about it. For now, let's do build system clean-up and spend time on Deer Park.... (14:05)

Thursday 26 May 2005

  • "Browse the web at an angle" - Picture taken during Robert O'Callahan's SVG/canvas presentation at X-Tech May 26, 2005.... (04:29 | 4 Comments)

Monday 16 May 2005

  • Status update for week ending May 13, 2005 - Highlights - Firefox 1.0.4 security firedrill, release turnaround in less than a week! - all new build machines mounted in colo, most configured for building, rest on their way - pending (as of May 13) Thunderbird 1.0.2 locales have been released... (13:52 | 2 Comments)

Friday 6 May 2005

  • Status update for week ending May 6, 2005 - Highlights - Firefox trunk builds now include Canvas. (Linux builds with Canvas are still experimental, see next item.) - Progress made on new Firefox trunk Linux build system -- builds being QA'd by MoFo staff. - bryner landed his fastback patch!... (20:06 | 2 Comments)

Wednesday 4 May 2005

  • Fastback Inside! - Earlier today bryner landed his "bfcache" patch, a set of changes to cache DOM presentation information in the browser. What does this mean to you and our users? With the feature enabled in Firefox, where before the browser needed to re-render each page from a local cache of documents, now when you click back and forward the most recently viewed pages appear instantly! We are approaching our first Deer Park alpha release and as such the feature is currently pref'd off by default. Thanks to bryner and the Gecko hackers (among them boris, brendan, dbaron) for making this feature happen! Want to give it a try? As Jeff is right to point out below, trunk builds are only for the brave at this point.. this software may toast your hard drive and sparks may shoot out of your computer giving you a permanent orange afro! I offer NO GUARANTEES that bad things won't happen and won't be able to support anyone that has a problem caused by some heinous bug in a trunk build. That said, the build works well enough for my day-to-day use. For those of you still reading that remain undaunted, follow these steps to give bfcache a whirl: Download and install the latest Firefox trunk nightly. Linux MacOS X Windows Run Firefox and type 'about:config' in the location bar. Right-click on the main content area. Select New Select Integer Enter the preference name 'browser.sessionhistory.max_viewers' and click OK. Enter '5' and click OK. Shutdown and restart Firefox. Take the feature for a test drive! View a large web page with lots of elements, like planet.mozilla.org or mozillaZine feedHouse. Next, go to another page, like Slashdot. Click Firefox's Back button. If the preference is properly enabled, the previous page should appear instantly. Click the Forward button to see it work again with Slashdot. If you find a bug in this feature, or if you find a problem with viewing pages even while bfcache is pref'd off, please report a bug on the problem and place it under the "History: Session" component. NOTE: Don't confuse the "browser.sessionhistory.max_viewers" pref with "browser.sessionhistory.max_entries". max_viewers is the pref that needs to be set. You must create "browser.sessionhistory.max_viewers" so it holds an integer value (5 is a good start) as by default it's unset.... (17:32 | 36 Comments)

Friday 29 April 2005

  • Status update for week ending April 29, 2005 - Highlights - Firefox hit 50 million downloads! - SVG now included in Firefox trunk builds for Windows and Mac - Lead Sysadmin position notice posted on MoFo careers page - 2 new Mac build systems added, full configuration pending - met with bclary about JavaScript QA while he visited MoFo - met with tor about SVG while he visited MoFo... (16:27 | 4 Comments)

Tuesday 26 April 2005

  • SVG here we come - SVG is now enabled in the Firefox trunk nightlies: windows, mac Linux coming soon. Update: I should choose my words more carefully. s/enabled/included/... (14:14 | 17 Comments)

Wednesday 6 April 2005

  • Firefox 1.0.3 and Mozilla Suite 1.7.7 candidates available for testing - Asa has posted about our latest builds and in an effort to help him spread the word, I'll post too.. We've ironed out some issues on the branches and came up with a set of Firefox 1.0.3 and Suite 1.7.7 builds that we'd like to get eyes on for testing purposes. If you'd like to join in the testing effort, feel free to try out any or all of them. The more testing they can get the more solid the releases we can offer back to you! Thanks! Firefox 1.0.3 Linux Mac Windows Suite 1.7.7 Linux GTK1 Linux GTK2 Mac Windows... (21:31)

Monday 28 March 2005

  • Congrats to Bryner! - My congratulations to Brian for his recent move to Google! While I'm here I'll say thanks for the help you continue to offer when I get stuck on those really difficult build problems. Best of luck to you, man.... (22:40 | 4 Comments)

Tuesday 22 March 2005

  • Wondering why there are no .zip files for the Fx and Tb 1.0.2 releases? - Some people have been wondering why there are no .zip files for the Firefox and Thunderbird 1.0.2 releases. The reason for this is that the Mozilla Foundation has discontinued issuing them for our major releases to avoid the user confusion it was causing. During previous releases, a number of people grabbed the .zip package and used that in their Firefox installation directory. When Firefox 1.0.1 rolled around, they grabbed the .exe installer package. When they setup 1.0.1 using the installer, a lot of them chose the same installation location in which they'd unzipped the .zip file. This led to their Firefox 1.0.1 installation crashing repeatedly and (very!) mysteriously. We tracked down the cause of the large number of Talkback incidents we were receiving late-late-late into the night of the Firefox 1.0.1 release to being caused by misuse of the .zip and .exe packages. It was obvious then there was no quick fix. The smartest thing for us to do was reduce our configuration management/QA complexity while simplifying user experience by assisting those less savvy among us in selecting the correct file to use for their platform. For Windows, people should use the .exe package. If you're a Mozilla developer and love the .zip files, rest assured they aren't going away completely. While we won't issue the .zip package with the rest of the major release files, we will still issue these packages in their standard nightly form.... (17:13 | 187 Comments)
  • Snow Crash - Photo courtesy of morgamic.... (15:30)

Saturday 12 March 2005

  • Cross-compiling Mac executables from Intel x86 - In drawing up a vision for how to turbocharge the Mozilla Foundation's build farm, I've read many cool things that could lead to builds taking very little time. One of the cooler ideas (but not the coolest) is to cross-compile our Mac builds straight from Intel x86 boxes. I've asked around the office and while we all agree that this is intriguing, we wonder what drawbacks we might face. Do we lose a lot of optimizations we would otherwise get if we were compiling natively? Of course, the resulting binaries would need to be sent to a Mac platform for testing, but if we could more closely tie our build farm story to one type of hardware platform (instead of needing G4s, G5s, and/or Xserve G5s, as well), we would be able to go farther, faster, and do so at less cost. Anyone out there have experience with cross-compiling Mac executables from Intel x86? Did your build systems go mad and cause your hard drives to spin out of control? Did your Intel x86 box instantly take on the silver gleam of an Xserve? Spin your tall tales (with a dose of truth about whether or not it actually worked) here!... (20:59 | 14 Comments)

Wednesday 23 February 2005

  • Making web applications more user-friendly - Such an interesting article from Adaptive Path's Jesse Garrett today entitled "Ajax: A New Approach to Web Applications" highlighting the recent trends in web apps to make them more user-friendly. This provides a good summary of the technical achievements that power the latest breed of Google apps (ie. Gmail, Google Suggest, Google Maps) without the in-depth codeline play-by-play. Brendan pointed me at Dojo, too, which is a browser toolkit that aims to provide a uniform interface to the capabilities that browsers from Firefox to Opera to IE provide. One thing's for sure: the demonstration Google Maps provides rocks, but it's still just the tip of the iceberg of what can be done when common JavaScript techniques are coupled with the DOM and client-server RPC.... (18:07)

Tuesday 15 February 2005

  • Bonsai linkification - If you've been looking closely enough you'll have noticed that the commit message linkification on Tinderbox and Bonsai has gotten smarter. Now if a group of numbers is preceded by "attachment ", the link will be auto-transformed into a link to a Bugzilla attachment. Example... (11:32)

Sunday 13 February 2005

  • Modifying Tinderbox, Bonsai, and LXR; Call for Suggestions - Slowly but surely I've been weaving my way through the Tinderbox, Bonsai, and LXR code and straightening out any parts that seem crooked. I've fixed some regressions around the layout of usernames on Tinderbox pages which was giving bad links to their commit info, properly URL-escaped committer names (so we can see what people with '+' in their usernames have changed), and, with the proper encouragement, implemented the equivalent of an "I'm feeling lucky" search for file find in LXR. (If you have an LXR keyword set up for file searching append '&lucky=1'. Hi Ben!) I can't leave out Bonsai, though, due to the amount of time I've spent getting a new installation enabled for l10n work. Packaging was never done for this tool, which means that if the person standing up a new instance isn't familiar with it, this can be pretty challenging. But the challenge is good because it points out one area in particular that the tool needs work. I'm putting a lot of thought into how tools like these are used on the Mozilla project and how they could be made better. What works and what doesn't, strengthening them while at the same time making them more flexible. They are essential for our work and could prove just as invaluable to those projects which aren't using them already.... (16:34)