Schedule Driven Releases: Channel Strategy

Ehsan Akhgari ehsan.akhgari at
Thu Apr 21 17:54:00 UTC 2011

For whatever it's worth, there is absolutely no guarantee that stuff which
gets merged into Aurora is going to be good for Thunderbird, as far as build
bustages are concerned.  The aurora merges are done on schedule, without
paying attention to the tree status on mozilla-central even.  So, if
Thunderbird bases itself on Aurora, at each merge the builds may break, and
Thunderbird devs would have 6 weeks worth of changes on their hands to find
the culprit from.


On Thu, Apr 21, 2011 at 1:42 PM, Mark Banner <mbanner at> wrote:

> 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 anyway).
> Mark.
> _______________________________________________
> tb-planning mailing list
> tb-planning at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list