Schedule Driven Releases: Channel Strategy
mbanner at mozilla.com
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
>> 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
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