In today's Firefox 3 Meeting we took a hard look at the amount of P1
blockers remaining for Beta 3, and the P2 blockers remaining, and
decided that we're still going to do a Beta 3 code freeze tonight, but
will be adding another milestone (Beta 3.1? :) ) before moving on to
Release Candidate builds.
Firefox 3 Beta 3
There are currently more than 60 bugs marked P1 and blocking-firefox3+
or blocking1.9+ with some target milestone. We need to reduce this list
for code freeze tonight.
If you own one of these bugs, and believe that your feature MUST get
into Firefox 3 Beta 3, please make sure to set the target milestone to
"Firefox 3 Beta 3" or "mozilla1.9 beta 3" (note: these used to be "M11",
but have been renamed). Please do this ASAP.
Code freeze is tonight, chatter is in #granparadiso on IRC. We will be
driving the list of blocking+, P1, target=beta 3 bugs to zero. This
query shows that list:
Tree management after freeze
After tonight's freeze we'll be holding the tree closed to bake the beta
for the rest of the week. During that time we should be focusing on
regression spotting and fixing, and all patches must have explicit
approval using the blocking1.9b3 flag before landing. (This is the same
process we've used in the past two betas)
Assuming all goes well, we'll hand the tree over to the Build team on
Monday to generate Firefox 3 Beta 3 release candidates.
We continue to remain frozen on strings, meaning that any string change
will require the "late-l10n" keyword, and justification for the late
change. We will also require that any changes which could affect add-ons
to be tagged with a "late-compat" keyword so that add-on developers can
keep themselves up to date.
Firefox 3 Beta 4 Schedule
Our goal is to do a quick turnaround on Firefox 3 Beta 4, but we cannot
provide a good estimate until we know the size and scope of blockers
remaining after the Beta 3 codefreeze. To help us, if bug owners of
blocker bugs could add a time estimate using the notation [swag: <time
estimate in days>] in the status whiteboard, that would help a lot.
As soon as we know more about the schedule for this beta, we'll post to
Firefox Release Drivers (mike, mike, mike, damon and vlad)
What about blockers with no owner? eg
which prevents me from working on firebug for FF3.
Good point. The people triaging blocking flags should be ensuring that
all P1/P2/P3 blockers have owners, really.
> Tree management after freeze
> After tonight's freeze we'll be holding the tree closed to bake the
> beta for the rest of the week. During that time we should be focusing
> on regression spotting and fixing, and all patches must have explicit
> approval using the blocking1.9b3 flag before landing. (This is the
> same process we've used in the past two betas)
I believe you meant "approval1.9b3" instead of "blocking1.9b3" above. :)
Reed Loden - <re...@reedloden.com>
> How is the tree freeze working with regards to tests? Are we still
> allowed to land tests while the tree is frozen?
Don't they come under the NPOTB rules?
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Are Cheerios really donut seeds?
* TagZilla 0.066.6
Indeed I did!
Slightly after midnight we froze the tree for beta 3. This means that
from this point on, only patches with approval1.9b3+ will be allowed to
How do you get that flag? Request it, and the Firefox 3 Drivers (schrep,
damons, mconnor, vlad and I) will triage that list twice daily at least.
We're going to be VERY conservative, so the onus will be upon you to
explain in the bug why you believe that the patch *must* be in this
milestone as opposed to waiting for the tree to unfreeze early next week.
If you believe that there is a bug that MUST BE FIXED for Firefox 3 Beta
3, please make sure that you nominate it for blocking-firefox3? or
blocking1.9? and have the target milestone set to "Firefox 3 beta 3" or
"mozilla1.9 beta 3" -- we will be triaging that set of nominations daily
as well to spot these must-fix issues. Please provide rationale!
For our localizers, cut-off date is unchanged,
> This means all localization changes will need to be checked into CVS
> by 8 AM UTC on February 4th to make beta 3.
There'll be further news on B4 as it comes, and we'll start an opt-in
thread for B3, probably tomorrow. This post is not the opt-in thread.
Watch out to get your tinderboxens green, and your buildbot stats. I'll
probably land another code change there today or tomorrow, angst. Junk
detection and PEs for DTDs, should be good.
Regarding B4 and beyond:
We will, at some point, need to freeze l10n. To clarify terminology,
string-freeze is on now, that's freezing strings in en-US. Freeze l10n
is closing down on check-ins to our localizations.
I wouldn't want to freeze l10n before code freeze for RC1, but I'm not
sure if that's not too early still. I'm tempted to postpone deciding
that to after B4, what do you guys think?
As OS/2 is NPOTDB can I continue to check in stuff as long as it's OS/2
only? I could ask for approval1.9b3 before checking in OS/2 stuff to
shared files if you want me to (so that someone can e.g. check if I closed
I didn't have as much time to devote to programming in the last weeks, so
we are quite a bit behind already on the fixes that I wanted to have in
Yes. Tests always welcome.