<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/08/2012 19:23, Magnus Melin
wrote:<br>
</div>
<blockquote cite="mid:50240035.5010106@iki.fi" type="cite">On
09.08.2012 15:52, Mark Banner wrote:
<br>
<blockquote type="cite">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.
<br>
<br>
</blockquote>
<br>
For us not on the release floor - what is it that makes it so much
less work to do a beta vs a release?
<br>
</blockquote>
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.<br>
<br>
So you've already got several times the effort of pushing out a
single beta.<br>
<br>
On top of that, for final releases you need to make sure that:<br>
<ul>
<li>You've addressed all the bugs you're tracking for the release
(for beta we don't necessarily fix all the bugs being tracked as
they can be fixed during the cycle)</li>
<li>Prompt L10n to finish their localisations<br>
</li>
<li>Web pages (release notes, system requirements etc) are written
and agreed with any blog/press documents prepared<br>
</li>
<li>If you have a what's new page, then that needs to be completed
and pushed out to localisers (which is basically land n copies
of it, file 50+ bugs, and then help out localisers with landing
etc)</li>
</ul>
<p>Mark.<br>
</p>
</body>
</html>