Proposed Release Plan changes

Magnus Melin mkmelin+mozilla at
Thu Aug 9 18:23:49 UTC 2012

On 09.08.2012 15:52, Mark Banner wrote:
> On 09/08/2012 11:43, Ben Bucksch wrote:
>> On 09.08.2012 08:25, Magnus Melin wrote:
>>> If we absolutely can't do full rapid releases, I'd still propose we 
>>> have those releases as some kind of blessed builds (hey, even 
>>> nightlies auto-update!), but make more noise about the ESR-based 
>>> releases. From a community engagement perspective it's indeed very 
>>> bad if the time until your contribution is live grows further. 
> The problem with "blessed builds" is that you basically need to call 
> them betas, which is roughly what you get in the proposed plan anyway.
>> I think most users what ESR - in fact they want it even slower than 
>> current ESR.
>> Some other geek users want the latest and greatest. They currently 
>> get that with the rapid releases, so they use the releases - which is 
>> why we don't find regressions until we have released, as Ludo said. 
>> Essentially, our releases are the betas, which isn't good. So, if we 
>> switch to ESR-based releases as Mark proposed, then make "betas" 
>> based on the rapid releases, and have the nightlies based on m-c for 
>> developers and the really brave users/testers, then we should cover 
>> most bases and get good testing coverage. (This is assuming that 
>> making a beta release isn't much work, because there's very little QA 
>> involved.)
> 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?


More information about the tb-planning mailing list