In today's Firefox 3 Meeting[1] 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 dev-planning.
cheers, Firefox Release Drivers (mike, mike, mike, damon and vlad)
Mike Beltzner wrote: > Hey everyone, ... > 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.
Mike Beltzner <beltz...@mozilla.com> wrote: > 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. :)
On Tue, 29 Jan 2008 16:01:42 -0800 (PST), Shawn Wilsher wrote: > 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?
Phil
-- Philip Chee <phi...@aleytys.pc.my>, <philip.c...@gmail.com> http://flashblock.mozdev.org/http://xsidebar.mozdev.org 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
Reed Loden wrote: > I believe you meant "approval1.9b3" instead of "blocking1.9b3" above. :)
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 land.
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.
> 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 > land.
> 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.
Further:
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!
> 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?
> In today's Firefox 3 Meeting[1] 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 > dev-planning.
> 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)
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 ifdefs correctly). 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 beta 3...
