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
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.
> 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
> 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.
> 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!
> schrep wrote: >> Hi Folks,
>> Last night we hit Zarro bugs for Firefox 3. 3 New issues have >> arisen >> since then:
>> 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
>> 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.
Michael Connor <mcon...@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.
> 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
> 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.
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.
> 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.
> 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.
> 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.
>> 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
Thanks Gavin. Super-helpful. I've approved the bug. Can you land, clobber, and post here a CVS pull date for Build?
>> 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
Thanks Gavin. Super-helpful. I've approved the bug. Can you land, clobber, and post here a CVS pull date for Build?
>>> 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
> Thanks Gavin. Super-helpful. I've approved the bug. Can you land, clobber, > and post here a CVS pull date for Build?
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.
>>>> 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
>> Thanks Gavin. Super-helpful. I've approved the bug. Can you land, >> clobber, >> and post here a CVS pull date for Build?
> 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.
>>>>> 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
>>> Thanks Gavin. Super-helpful. I've approved the bug. Can you land, >>> clobber, >>> and post here a CVS pull date for Build?
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.
> 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.
Mike Beltzner wrote: Gavin Sharp 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
Builds have not yet started. Do the backout and post a new pull time.
On Sun, May 11, 2008 at 4:06 PM, schrep <sch...@mozilla.com> wrote: > Mike Beltzner wrote: > Gavin Sharp 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
> Builds have not yet started. Do the backout and post a new pull time.
Mike Beltzner wrote: Gavin Sharp 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
Builds have not yet started. Do the backout and post a new pull time.
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.
> On Sun, May 11, 2008 at 4:06 PM, schrep <sch...@mozilla.com> wrote: >> Mike Beltzner wrote: >> Gavin Sharp 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 >> Builds have not yet started. Do the backout and post a new pull time.
> On Sun, May 11, 2008 at 4:06 PM, schrep <sch...@mozilla.com> wrote: >> Mike Beltzner wrote: >> Gavin Sharp 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 >> Builds have not yet started. Do the backout and post a new pull time.
