Schedule Driven Releases: Channel Strategy

Mark Banner mbanner at
Thu Apr 21 17:42:15 UTC 2011

On 21/04/2011 13:47, Robert Kaiser wrote:
> Do you think you'll have enough users on all those four channels to 
> make them test-worthy? Note that we found on Firefox that less than 
> ~100k users on a "channel" probably doesn't get useful enough crash 
> stats for efficiently attacking stability (which is currently a 
> problem on both nightly and aurora), but Thunderbird might care less 
> about that aspect and rely on most crashes being core and detected by 
> us on the FF side anyhow.
I don't know how many users we're going to get. What I do think is that 
until we try it, we won't find out. Once we've tried it for a while, 
then we can assess how useful we think it is, if it turns out the 
balance is right, then we can assess what to do about it.

> Still, I have some concern about splitting the tester community too much.
I understand that concern, and I have it to. However, I think from the 
logical progression of following the release train and coordinating 
everything, then I think it is best to at least try the same style to 
begin with.

>> With this mapping, we'll also definitely need the Canary system
>> completing for the trunk builds.
> Actually, I'd think hat with this, you don't need the Canary system at 
> all, as anyone concerned with stability in the slightest sense will 
> use aurora-based builds and trunk should build against mozilla-central 
> proper exactly to find any compile, etc. problems as fast as possible, 
> while a Canary-style system papers over that and invites to not fixing 
> problems.
As Firefox is advertising, central/nightlies are for developers, aurora 
is where we expect people to have some stability, that's fine.

For developers working against comm-central and mozilla-central, we need 
to be supplying them a working build. If we have bustage caused by 
mozilla-central that for whatever reason takes a week to sort out, then 
that's a week where we can't do any landings - that's a sixth of the 
time for a release lost to landing things and getting testing before the 
next merge to aurora.

The other thing to remember is that mozilla-central merges to aurora are 
going to happen on the schedule and our aurora equivalent isn't going to 
have canary. Hence, if we're behind and we don't fix it in the six 
weeks, we're going to have a busted aurora and we're then going to have 
to do a bunch of work to fix that and central - which I think will 
provide the necessary incentive (plus we should be scheduling fixes in 


More information about the tb-planning mailing list