<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 19/11/2012 16:07, Kent James
(mobile) wrote:<br>
</div>
<blockquote cite="mid:50AA592B.4030200@caspia.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 11/19/2012 3:35 AM, Mark Banner
wrote:<br>
</div>
<blockquote cite="mid:50AA1999.4060502@mozilla.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Hi All,<br>
<br>
With the move to the new release model, and as per the plan,
we're still expecting to do new beta releases once per cycle.<br>
<br>
I would like to propose that we move the beta release to the
second week of a gecko rapid release cycle - i.e. although
Firefox would release a new gecko beta around the same time as a
new release point (e.g. 18.0b1 normally comes out a day after
17.0), we'd actually wait a week before building and releasing
Thunderbird 18.0b1.<br>
<br>
</blockquote>
I'm all in favor of moving the beta later, but I had assumed it
would be even later, like near the end of a rapid release cycle.
I've suggested that the betas be promoted as an "early adopter"
version of Thunderbird. If the beta is also an early adopter
version, it would be best to have the beta as late as possible.<br>
</blockquote>
I can see the argument, but I don't think that we generally gain
much just from gecko changes over the six weeks. Whilst it is true
that some of their crashes do affect us, I'm not sure that waiting
will actually help us.<br>
<br>
I think there's a balance of taking the new gecko late to give a
small bit more stability, or getting the new gecko out earlier so
that we can find problems in testing it that need to be fixed before
the next gecko gets to beta, or even the trunk version gets onto
aurora. <br>
<br>
What would you think about week 3?<br>
<br>
<blockquote cite="mid:50AA592B.4030200@caspia.com" type="cite"> Is
there any chance of doing both? My understanding was that the
rate of betas was being reduced to conserve resources. Since we
agreed to drop the mid-year full release, we are using less
resources than we were originally allocated. Could we use those
resources to have a two beta cycle, one at the point you suggested
and another at the end of the rapid release cycle?<br>
</blockquote>
What would a second beta release at the end of a cycle gain us
(except in the case where we had a really really critical issue in
beta)? If would have some stability fixes in, but they would come
during the next cycle anyway, which generally isn't far off.<br>
<br>
Rather than having two betas a cycle, I think I'd prefer to have the
folks not working directly on the releases to be more available to
work with the community for co-ordination, bug tracking, bug fixing,
QA etc.<br>
<br>
Mark<br>
</body>
</html>