Closing mozilla trunk for Firefox 3.1 Beta 3 code freeze

[Mike Beltzner]

(followup/reply-to mozilla.dev.planning / dev-
plan...@lists.mozilla.org)

Hey everyone,

As we approach the code freeze deadline for Firefox 3.1 / Gecko 1.9.1
Beta 3, I would like to propose that we restrict both trunk and branch
to the same set of checkin rules. Patches must land on mozilla-central
before the 1.9.1 branch, so this proposal aims to keep the activity on
trunk to a minimum to make it easier to land patches for our remaining
Beta 3 blockers: http://is.gd/gTFy

For a patch to land on mozilla-central, it would have to:
* fix a bug marked blocking1.9.1+ or blocking-firefox3+, or
* be marked with approval1.9.1+, or
* not affect Firefox build (tests, NPOTB changes)

Patches nominated for approval1.9.1 should:
* have tests, or a strong statement of what can be done in the absence
of tests
* have landed on trunk and baked for a few days (at least)
* have an assessment of performance impact
* have an assessment of risk

Once all the Beta 3 blockers land on mozilla-central, we would lift
these restrictions.

If you have any objections, please let me know. Otherwise Ted (who is
Sheriff tomorrow) will impose the rules at 9am EST.

cheers,
mike

[Reed Loden]

On Thu, 22 Jan 2009 20:00:30 -0500
Mike Beltzner <belt...@mozilla.com> wrote:

> For a patch to land on mozilla-central, it would have to:
> * fix a bug marked blocking1.9.1+ or blocking-firefox3+, or
> * be marked with approval1.9.1+, or
> * not affect Firefox build (tests, NPOTB changes)

How do we get approval1.9.1+ for patches that haven't yet baked/landed
on mozilla-central, considering the usual process is land on
mozilla-central first, wait a little bit, and then request approval for
the branch(es)?

~reed

--
Reed Loden - <re...@reedloden.com>

[Mike Shaver]

With difficulty, which is one of the desired tree-calming effects of
this change. Confidence through other testing will need to be quite
high; if it's not worth getting the testing that high, it should wait
until b3 has shipped.

Mike

[Mark Finkle]

> For a patch to land on mozilla-central, it would have to:
> * fix a bug marked blocking1.9.1+ or blocking-firefox3+, or
> * be marked with approval1.9.1+, or
> * not affect Firefox build (tests, NPOTB changes)

What about fennec-blocking1.0+ ?

[Mike Beltzner]

On 22-Jan-09, at 8:14 PM, Mike Shaver wrote:

> On Thu, Jan 22, 2009 at 8:04 PM, Reed Loden <re...@reedloden.com>
> wrote:
>> On Thu, 22 Jan 2009 20:00:30 -0500
>> Mike Beltzner <belt...@mozilla.com> wrote:
>>

>>> For a patch to land on mozilla-central, it would have to:
>>> * fix a bug marked blocking1.9.1+ or blocking-firefox3+, or
>>> * be marked with approval1.9.1+, or
>>> * not affect Firefox build (tests, NPOTB changes)
>>

>> How do we get approval1.9.1+ for patches that haven't yet baked/
>> landed
>> on mozilla-central, considering the usual process is land on
>> mozilla-central first, wait a little bit, and then request approval
>> for
>> the branch(es)?
>
> With difficulty, which is one of the desired tree-calming effects of
> this change. Confidence through other testing will need to be quite
> high; if it's not worth getting the testing that high, it should wait
> until b3 has shipped.

Indeed - there's a pretty big backlog of baking patches (http://is.gd/gUSi
) which I'll look through and could take some time to land already.
The goal here is to lock down hard for b3, then re-open again
afterwards. What we don't want is to delay our code freeze because we
have to wait for quiet checkin cycles.

cheers,
mike

[Mike Beltzner]

On 22-Jan-09, at 10:42 PM, Mark Finkle wrote:

>> For a patch to land on mozilla-central, it would have to:
>> * fix a bug marked blocking1.9.1+ or blocking-firefox3+, or
>> * be marked with approval1.9.1+, or
>> * not affect Firefox build (tests, NPOTB changes)
>

> What about fennec-blocking1.0+ ?

Nominate those for approval and poke me on IRC if you really need them
in over the weekend.

cheers,
mike