atom feed76 messages in Thoughts on next release after Ge...
FromSent OnAttachments
Mike SchroepferDec 18, 2007 5:14 pm 
John J. BartonDec 18, 2007 9:57 pm 
Mike SchroepferDec 18, 2007 10:59 pm 
Axel HechtDec 19, 2007 12:58 am 
Benjamin SmedbergDec 19, 2007 6:57 am 
Adam KowalczykDec 19, 2007 7:03 am 
MartijnDec 19, 2007 7:04 am 
Benjamin SmedbergDec 19, 2007 7:34 am 
Dan MosedaleDec 19, 2007 9:46 am 
Sergey YanovichDec 19, 2007 9:49 am 
Boris ZbarskyDec 19, 2007 9:56 am 
Benjamin SmedbergDec 19, 2007 10:08 am 
Sergey YanovichDec 19, 2007 10:21 am 
Benjamin SmedbergDec 19, 2007 10:49 am 
Mike SchroepferDec 19, 2007 10:54 am 
Mike SchroepferDec 19, 2007 10:58 am 
Sergey YanovichDec 19, 2007 12:24 pm 
John J BartonDec 19, 2007 1:12 pm 
Mike ShaverDec 19, 2007 1:46 pm 
John J BartonDec 19, 2007 2:48 pm 
smaugDec 19, 2007 3:36 pm 
Colin BarrettDec 19, 2007 3:42 pm 
Benjamin SmedbergDec 19, 2007 3:48 pm 
MartijnDec 19, 2007 5:11 pm 
Colin BarrettDec 19, 2007 5:14 pm 
Benjamin SmedbergDec 19, 2007 5:31 pm 
Benjamin SmedbergDec 19, 2007 5:35 pm 
Simon PaquetDec 19, 2007 6:14 pm 
Boris ZbarskyDec 19, 2007 8:35 pm 
Mike ShaverDec 19, 2007 9:02 pm 
46 later messages
Subject:Re: Thoughts on next release after Gecko 1.9 (a modest proposal)
From:Benjamin Smedberg (
Date:Dec 19, 2007 6:57:10 am

Mike Schroepfer wrote:

A) Big, invasive, destabilizing changes. These are the sort of tasks

7) Removal of XPConnect

I wouldn't call this "removal" but rather "fast-path DOM"... and I don't think it's a bucket-A item. I think it could implemented as a much smaller bucket-B item once the actionmonkey (tamarin JIT) stuff is landed.

B) Medium sized, significant in impact changes. These are non-trival, but better isolated. Easier to turn off or backout. Things such as:

1) XBL2

This is tricky: we could either

* implements XBL2 and keep mozilla-XBL -- this is safe and in bucket two, but has the problem that we're carrying around two significant infrastructures that will interact poorly

* replace mozilla-XBL with XBL2 -- this is probably much easier to implement correctly and quickly, but it involves rewriting our existing mozilla-XBL bindings in XBL2. In some cases we can come up with automatic transformations, but it will still be a pretty huge change that really should be in bucket A above.

Each team (depending on size of task) will be working on a separate Hg branch. We'll keep hg-central overall very high quality and

Note that several of these tasks have dependencies on eachother: XPCOMGC depends on AM stage 1 and stage 2. Exception support depends on XPCOMGC.

at once. Easier Hg merging, the try server, and other tools will make it much easier for folks to test out changes without first having to merge them to mainline.

We ship alpha's from hg-central early on in the process on a 6-8 week cadence. We'd strongly hope that 1-3 of the big (A) tasks is ready for ship during the schedule. However, since we are working on lots of smaller stuff in parallel if the big stuff takes longer than expected we still have a stable base and a set of improvements to go into a release.

A critical piece of this plan that I think we need to nail is directing our community of nightly testers. It's possible of course to simply have nightly testers on mozilla-central at all times, but I don't think this provides maximum leverage:

* Testers may want to actively follow one of the feature branches: e.g. the UE team will have experiments and ask for testing of those before they hit mozilla-central... an XBL2 branch will want testing from extension authors and interested developers before it is merged to mozilla-central.

* We don't want to orphan a nightly tester: if they have been testing a nightly from the UE branch, we'd like to keep them up to date nightly. If the UE branch stops being developed, we want to repatriate that user to mozilla-central

I think we can accomplish this through the update system and major update offers:

+-------------------------------+ | Minefield Update | | An update is available. You are currently using | the Minefield stable nightly builds. We are looking for | testers of the user experience branch. This branch contains | experiments in the user interface design of Firefox. Would you like to | update to the UE branch? | | [ Update ] [ No thanks ] | +-------------------------------+

Finally, I think that it may make sense to do an alpha every 4 weeks. I know that mconnor has been planning a monthly cadence for new UE features, and with an always-stable mozilla-central and release automation, I think we can schedule the alphas more frequently than we have. But I think we should make sure that we get automatic updates from alpha->alpha so we don't leave people stranded.