Something I have been thinking about lately is how we could make non-trivial changes to the application after it hits Beta. Yes, Beta. Google does something like this for Chrome for Android. Many changes we see in Chrome for Android (Beta) never make it to the release version.
Firefox for Android sees an insignificant user base until it hits Beta. Once on Beta, we start getting a lot of valuable feedback. Mozilla's traditional viewpoint on Beta is "no significant changes" which can put Firefox for Android is a sucky situation.
I want to move to a process that gets a Beta sized audience using the product, but still allowing Mozilla to make non-trivial changes based on early feedback. I see the 9 week Beta cycle as a way to do that.
Finkle
----- Original Message -----
> The main purpose of Aurora as a channel is to get early feedback on new
> Firefox versions with users that better represent our Beta/Release
> populations. Aurora users knowingly accept a lower quality bar than
> Beta/Release, as well as more frequent updates.
> Aurora is a fantastic tool, but it's my team's opinion that it doesn't make
> great use of the full six weeks allotted to it in each development cycle. We
> find most major Aurora issues in the first week or so after the merge, and
> critical Beta-blocking issues are typically resolved within days thereafter.
> We've verified this premise by taking a look at bugs tracked for Firefox 24,
> fixed in the Aurora timeframe.
> We have an informal saying in Release Management that we should always "get
> new code in front of the most users as soon as possible". Given that goal,
> I'd like us to spend even more of the 18 weeks with the much larger Beta
> population, since that population is the most applicable to Release in
> diversity and quality on Aurora is already fairly high. Here's my proposed
> "Coupled Train Model" (thanks to curtisk for the naming):
> * change the desktop/android train model to have two 9-week cycles rather
> than three 6-week cycles (still 18 weeks start to finish)
> * enable Aurora updates the day after release, rather than at the end of the
> week
> * merge mozilla-aurora to mozilla-beta as soon as critical quality issues
> have been resolved on both Aurora and Release (1-2 weeks after that)
> ** we'd utilize the 1-2 week overlap to push dot releases to the Beta
> population prior to Release (bonus functionality!)
> * continue to have certain features only enabled on Aurora and lower
> * continue to use mozilla-aurora and the Aurora population as a method of
> testing fixes prior to uplift to mozilla-beta
> * allow developers to focus on two pre-release Gecko versions at a time,
> rather than three
> This proposal sees the Aurora population as a shorter, intermediate step
> towards Beta testing rather than an equally weighted phase of development
> (in terms of time). A chart explaining the Coupled Train Model can be found
> at
https://pbs.twimg.com/media/BV7r23WCMAAROMP.png:large
> Things we're still considering, and we're meeting separately on:
> * a start date - current proposal is starting with Firefox 30 in the new year
> * a new string freeze date - current proposal is upon the merge to Beta,
> since features that aren't ready for release will be backed out by that
> point
> * an API freeze date, for add-on/plugin authors - still need to determine a
> hard date, but somewhere shortly after the merge to Beta
> * when (and from where) to branch future FxOS releases
> * security update frequency and the bar for a security dot release (given
> platform updates every 9 weeks)
> * how we would want to communicate the Aurora/Beta "releases" (perhaps
> together?)
> Thanks to all those who have already provided feedback (and early support) at
> the Open Sessions on Releases in Santa Clara and Toronto. I'd love to hear
> even more feedback from those community members who weren't able to attend.
> -Alex