Proposed Release Plan changes

Justin Wood (Callek) callek at gmail.com
Fri Aug 10 17:49:47 UTC 2012


Mark Banner wrote:
> On 09/08/2012 19:23, Magnus Melin wrote:
>> On 09.08.2012 15:52, Mark Banner wrote:
>>> Betas aren't too much work, we'd probably do one a cycle for most
>>> cycles (assuming no significant issues found for the beta users),
>>> except during the cycles leading up to release when we'd ramp it up
>>> again. The only time we'd do something different would be for
>>> intermediate releases, which would have to have betas based on the
>>> Gecko 17 route, but would include a lot of the fixes from the trunk.
>>>
>>
>> For us not on the release floor - what is it that makes it so much
>> less work to do a beta vs a release?
> The main thing to remember is that for a release you need to do a
> minimum of 2 betas (one at the start of the Gecko cycle to pick up
> gecko, one at the end to pick up any fixes through the cycle), probably
> 4 or 5 as you'll want to incrementally include the latest release.
>
> So you've already got several times the effort of pushing out a single beta.

I do agree with your logic in this e-mail. I would however advocate for 
2 betas every cycle rather than 1.

"beta 1" (matching Firefox beta 1)
and "beta 2" (matching Firefox Beta 5/6)

This will allow for better regression hunting finding issues for code 
that gets backported to beta. (whether it be gecko changes that break 
us, or mail changes the community drives)

If you have no intent of doing a full QA run on these betas, it is not 
much additional work at all.

-- 
~Justin Wood (Callek)




More information about the tb-planning mailing list