August 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)