Proposed Release Plan changes
mkmelin+mozilla at iki.fi
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
> 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