Firefox 3 RC1 Status

1 view
Skip to first unread message

schrep

unread,
May 9, 2008, 1:24:55 PM5/9/08
to
Hi Folks,

Last night we hit Zarro bugs for Firefox 3. 3 New issues have arisen
since then:

1) under investigation: https://bugzilla.mozilla.org/show_bug.cgi?id=432836
2) Bad start time Mac (Ts) regression from a patch on May 7:
https://bugzilla.mozilla.org/show_bug.cgi?id=432950
3) One follow-up issue from Key hell (karlt to provide bug)

There were 2 css changes + one update to the icon I approved.
Everything else was minused. If it is not a show-stopper at this point
we are not taking it.

Plan we are trying to hit:

a) Bake RC1 as long as we can (to make sure all the changes that
landed this week are clean)
b) This weekend: Kickoff builds for RC1
c) Monday afternoon begin the QA cycle for RC1
d) Keep the tree closed so build and IT can run some maintenance

You can track build work here:

http://wiki.mozilla.org/Firefox_3.0rc1:BuildNotes

and QA work here:

http://wiki.mozilla.org/QA/Firefox3/TestResults/RC1

The QA cycle for RC1 is more extensive than the betas since this may be
our last milestone. If no unexpected issues arise RC1 should ship late May.

Best,

Schrep

schrep

unread,
May 9, 2008, 8:54:36 PM5/9/08
to
Hi Folks,

We are down to:

https://bugzilla.mozilla.org/show_bug.cgi?id=432836
which will be fixed shortly by a back-out of
https://bugzilla.mozilla.org/show_bug.cgi?id=393246

We also checked the list of approved patches (thanks to a frenzy of help
on irc today) and there were about 19 that never landed. None of them
are critical enough to block so we are good there.

We'll let things settle on Saturday and kickoff the builds on Sunday.
If you have a *showstopper*, must block release, cannot wait for 3.0.1,
please nominate with a clear explanation of why. Fair warning that our
criteria for showstopper is pretty strict at this point since any new
bug will hold up the entire release. We'll watch the queue this weekend.

Cheers!

Schrep

P.S. WOOOOOOOO HHHHOOOOOO!

Michael Connor

unread,
May 9, 2008, 9:01:19 PM5/9/08
to schrep, dev-pl...@lists.mozilla.org
Backed out and clobbered. Assuming all stays green on the clobbers,
we should be able to use 2008/05/09 21:00 as the cutoff for build.

-- Mike

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Reed Loden

unread,
May 10, 2008, 12:31:12 AM5/10/08
to dev-pl...@lists.mozilla.org
On Fri, 9 May 2008 21:01:19 -0400
Michael Connor <mco...@mozilla.com> wrote:

> Backed out and clobbered. Assuming all stays green on the clobbers,
> we should be able to use 2008/05/09 21:00 as the cutoff for build.

I had two other Linux patches (GTK stock icon stuff) ready to land for
Firefox 3, so I landed them and re-clobbered Linux. 2008-05-09 21:00 PDT
includes those check-ins, so the proposed cutoff date still works.

~reed

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

Marco Zehe

unread,
May 10, 2008, 2:28:59 AM5/10/08
to
As per Gavin, landed assertion fix for bug
https://bugzilla.mozilla.org/show_bug.cgi?id=429617>

Marco

Gavin Sharp

unread,
May 10, 2008, 2:48:54 AM5/10/08
to Marco Zehe, dev-pl...@lists.mozilla.org
On Sat, May 10, 2008 at 2:28 AM, Marco Zehe <mz...@mozilla.com> wrote:
> As per Gavin, landed assertion fix for bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=429617>
>
> Marco

Just to be clear, the assertion fix Marco landed was a DEBUG-only
change to fix an assertion that was checked in as part of the approved
patch. The only reason the bug was not resolved when we looked through
unresolved bugs with a1.9+ earlier today was that it was reopened to
ensure that the assertion was fixed.

Given that the change posed no risk to the release, I recommended
Marco land it so that it could be included in RC 1 (it avoids unneeded
console noise should the RC 1 tag become the final release tag).
Including it means using a more recent cut-off date than the
previously mentioned 21:00 PDT. 2008-05-09 24:00 PDT would work.

Gavin

schrep

unread,
May 10, 2008, 10:19:28 AM5/10/08
to Gavin Sharp, Marco Zehe, dev-pl...@lists.mozilla.org
Thanks Gavin.

I looked through the nom list and the only thing that is a possible
serious issue is:

https://bugzilla.mozilla.org/show_bug.cgi?id=431802

Marco can you explain why this is a showstopper?
Gavin/MConnor can I get a risk assessment?

Best,

Mike

schrep

unread,
May 10, 2008, 10:19:28 AM5/10/08
to Gavin Sharp, dev-pl...@lists.mozilla.org, Marco Zehe
Thanks Gavin.

I looked through the nom list and the only thing that is a possible
serious issue is:

https://bugzilla.mozilla.org/show_bug.cgi?id=431802

Marco can you explain why this is a showstopper?
Gavin/MConnor can I get a risk assessment?

Best,

Mike

Gavin Sharp

unread,
May 10, 2008, 10:47:27 AM5/10/08
to schrep, dev-pl...@lists.mozilla.org, Marco Zehe
On Sat, May 10, 2008 at 10:19 AM, schrep <sch...@mozilla.com> wrote:
> Thanks Gavin.
>
> I looked through the nom list and the only thing that is a possible serious
> issue is:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=431802
>
> Marco can you explain why this is a showstopper?
> Gavin/MConnor can I get a risk assessment?

I think the risk is low, and that we should take it.

It fixes an flaw in the autocomplete controller's nsITreeView
implementation that was never noticed because autocomplete trees don't
have nested rows (and in fact URL bar autocomplete doesn't even use a
tree at all, so this only affects content/search bar autocomplete).
The only caller in the tree that I could find that calls this API for
autocomplete treeviews is accessibility code, when it tries to find
the parent of the row. Returning -1 is the correct way to indicate "no
parent", which is the case for all autocomplete rows. The xpfe
autocomplete widget doesn't implement this method at all - more
evidence that it doesn't affect cases outside of accessibility.

Gavin

schrep

unread,
May 10, 2008, 10:49:35 AM5/10/08
to Gavin Sharp, dev-pl...@lists.mozilla.org, Marco Zehe

Thanks Gavin. Super-helpful. I've approved the bug. Can you land,
clobber, and post here a CVS pull date for Build?

Best,

Schrep

schrep

unread,
May 10, 2008, 10:49:35 AM5/10/08
to Gavin Sharp, dev-pl...@lists.mozilla.org, Marco Zehe

Thanks Gavin. Super-helpful. I've approved the bug. Can you land,

Gavin Sharp

unread,
May 10, 2008, 11:01:55 AM5/10/08
to schrep, dev-pl...@lists.mozilla.org, Marco Zehe

Mike Beltzner

unread,
May 10, 2008, 11:45:46 AM5/10/08
to Gavin Sharp, dev-pl...@lists.mozilla.org, schrep, Marco Zehe
All,

It looks like we're going to take bug 433018 (https://bugzilla.mozilla.org/show_bug.cgi?id=433018
) as the best way to work through a situation where we have a pref
with no direct UI (see the bug for details) in order to minimize
potential user confusion.

Shouldn't affect the handoff to build later today.

cheers,
mike

On 10-May-08, at 11:01 AM, Gavin Sharp wrote:

Michael Connor

unread,
May 10, 2008, 12:14:20 PM5/10/08
to Mike Beltzner, dev-pl...@lists.mozilla.org, Gavin Sharp, schrep, Marco Zehe
Landed and clobbered.

Should be able to use 9:15 PDT as a new cutoff.

Almost there!

-- Mike

On 10-May-08, at 11:45 AM, Mike Beltzner wrote:

> All,
>
> It looks like we're going to take bug 433018 (https://bugzilla.mozilla.org/show_bug.cgi?id=433018
> ) as the best way to work through a situation where we have a pref
> with no direct UI (see the bug for details) in order to minimize
> potential user confusion.
>
> Shouldn't affect the handoff to build later today.
>
> cheers,
> mike
>
> On 10-May-08, at 11:01 AM, Gavin Sharp wrote:
>
>> Landed and clobbered:
>>
>> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-05-10+07%3A00&maxdate=2008-05-10+08%3A05&cvsroot=%2Fcvsroot
>>
>> 2008-05-10 08:05 PDT works as a cutoff.
>>
>> Gavin
>>
>> On Sat, May 10, 2008 at 10:49 AM, schrep <sch...@mozilla.com> wrote:

Gavin Sharp

unread,
May 11, 2008, 3:49:12 PM5/11/08
to Michael Connor, Mike Beltzner, schrep, Reed Loden, dev-pl...@lists.mozilla.org
We took bug 432938 at the last minute, but the patch wasn't tested, so
it actually broke error page favicons on Linux (bug 433241). There's a
patch in bug 433241 that works around the issue, but I'd feel better
at this point with just backing out the patch for bug 432938. I think
we should back it out for RC1 if possible, though I realize that
getting yet another cut-off date for RC1 might not be desired at this
stage. We should definitely include the backout in an RC2 if that
happens.

Gavin

Mike Beltzner

unread,
May 11, 2008, 3:56:29 PM5/11/08
to Gavin Sharp, dev-pl...@lists.mozilla.org, Reed Loden, schrep, Michael Connor

I agree. If the tree's been green, and if build has not yet started,
then we should back that out and give them new CVS cutoff times.

cheers,
mike

schrep

unread,
May 11, 2008, 4:06:50 PM5/11/08
to Mike Beltzner, Gavin Sharp, dev-pl...@lists.mozilla.org, Reed Loden, Michael Connor
Mike Beltzner wrote:

Builds have not yet started. Do the backout and post a new pull time.

Gavin Sharp

unread,
May 11, 2008, 4:18:29 PM5/11/08
to schrep, dev-pl...@lists.mozilla.org, Reed Loden, Michael Connor

schrep

unread,
May 11, 2008, 4:06:50 PM5/11/08
to Mike Beltzner, Reed Loden, dev-pl...@lists.mozilla.org, Gavin Sharp, Michael Connor
Mike Beltzner wrote:
Gavin Sharp wrote:

Builds have not yet started. Do the backout and post a new pull time.

John O'Duinn

unread,
May 11, 2008, 4:30:06 PM5/11/08
to Mike Beltzner, Reed Loden, dev-pl...@lists.mozilla.org, Gavin Sharp, schrep, Michael Connor
hi;

Builds have *not* yet started. It will be late tonight sometime (PST) ==
morning GMT.

I'd say go ahead with the backout, if you havent already, and just tell
us the new CVS cutoff times when you're done.


tc
John.
=====


Mike Beltzner wrote:
> On 11-May-08, at 3:49 PM, Gavin Sharp wrote:
>
>> We took bug 432938 at the last minute, but the patch wasn't tested, so
>> it actually broke error page favicons on Linux (bug 433241). There's a
>> patch in bug 433241 that works around the issue, but I'd feel better
>> at this point with just backing out the patch for bug 432938. I think
>> we should back it out for RC1 if possible, though I realize that
>> getting yet another cut-off date for RC1 might not be desired at this
>> stage. We should definitely include the backout in an RC2 if that
>> happens.
>
> I agree. If the tree's been green, and if build has not yet started,
> then we should back that out and give them new CVS cutoff times.
>
> cheers,
> mike

schrep

unread,
May 11, 2008, 5:01:15 PM5/11/08
to Gavin Sharp, dev-pl...@lists.mozilla.org, Reed Loden, Michael Connor
Thanks Gavin,

https://bugzilla.mozilla.org/show_bug.cgi?id=433192

Is the only new bug I'm worried about.

Mike

schrep

unread,
May 11, 2008, 5:01:15 PM5/11/08
to Gavin Sharp, dev-pl...@lists.mozilla.org, Reed Loden, Michael Connor
Thanks Gavin,

https://bugzilla.mozilla.org/show_bug.cgi?id=433192

Is the only new bug I'm worried about.

Mike

Karl Tomlinson

unread,
May 11, 2008, 8:53:34 PM5/11/08
to
schrep <sch...@mozilla.com> writes:

> https://bugzilla.mozilla.org/show_bug.cgi?id=433192
>
> Is the only new bug I'm worried about.

Landed a fix for this:

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&cvsroot=%2Fcvsroot&date=explicit&mindate=1210552740&maxdate=1210552792&who=karlt%2B%25karlt.net

New pull date is "2008-05-11 17:50:00 PDT"

Just waiting for unit/perf tests to cycle.

schrep

unread,
May 11, 2008, 9:49:43 PM5/11/08
to Karl Tomlinson

Once we finish build/unit/perf cycle we are ready to go for RC1.

Nick Thomas

unread,
May 12, 2008, 5:26:04 AM5/12/08
to
Tagging has now started for 3.0 RC1 Build1
Reply all
Reply to author
Forward
0 new messages