Closed Bug 492464 Opened 11 years ago Closed 11 years ago
_4 _8 _RTM to mozilla-1 .9 .1
mozilla-1.9.1 is using NSPR_4_7_4_RTM right now. The Fennec team wants me to push NSPR_4_8_BETA1 to mozilla-1.9.1 for Windows Mobile support. (See bug 456449 comment 93.) I will also commit to releasing NSPR_4_8_RTM and pushing it to mozilla-1.9.1 no later than the second release candidate of Firefox 3.5, to ensure that Firefox 3.5 final uses an RTM tag (as opposed to a Beta tag). I didn't request a review on the patch because all the changes in the patch have been reviewed elsewhere, and the patch is too big to review anyway. NSPR_4_8_BETA1 has been used in mozilla-central since last Friday, 2009-05-08.
Attachment #376835 - Flags: approval1.9.1?
Attachment #376835 - Flags: approval1.9.1? → approval1.9.1+
Comment on attachment 376835 [details] [diff] [review] Diffs between NSPR_4_7_4_RTM and NSPR_4_8_BETA1 Per discussion... there is no guarantee that there will be a second RC. We'll take an RTM tag when it's available (even for 22.214.171.124), but don't want to take a beta tag.
Attachment #376835 - Flags: approval1.9.1+ → approval1.9.1-
(In reply to comment #0) > I will also commit to releasing NSPR_4_8_RTM and > pushing it to mozilla-1.9.1 no later than the second > release candidate of Firefox 3.5, to ensure that > Firefox 3.5 final uses an RTM tag (as opposed to > a Beta tag). There is no planned second release candidate, Wan-Teh. We'll take 4_8_RTM by the code freeze for the first (and only planned) release candidate, which means we'd need it by May 20th; can you make that date? Otherwise we'll have to push this off until 126.96.36.199 as I haven't seen any reason why Firefox 3.5 should block on this. > NSPR_4_8_BETA1 has been used in mozilla-central since > last Friday, 2009-05-08. Good to know!
Assignee: wtc → nobody
Component: Build Config → General
Flags: blocking1.9.1? → blocking1.9.1+
QA Contact: build-config → general
Summary: Push NSPR_4_8_BETA1 to mozilla-1.9.1 → Push NSPR_4_8_RTM to mozilla-1.9.1
What's the earliest we can get it? For a change to something like NSPR the more baking on the branch the better, really.
Comment on attachment 376835 [details] [diff] [review] Diffs between NSPR_4_7_4_RTM and NSPR_4_8_BETA1 I pushed NSPR_4_8_BETA1 to mozilla-1.9.1 in changeset 5d04fb10d45a: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5d04fb10d45a I can release NSPR_4_8_RTM by May 20th. I will release NSPR_4_8_BETA2 and test it in mozilla-central right away. Ben, why did you give this patch approval1.9.1+ and then change it to approval1.9.1-?
I marked it too quickly in a meeting: we decided we didn't want to take a beta tag on the 1.9.1 branch.
I was confused. Sorry. I think it's better to leave NSPR_4_8_BETA1 in mozilla-1.9.1 and replace it with NSPR_4_8_RTM in a few days. Agreed?
Oh, I see it already landed. Yes, no need to back it out.
I just pushed NSPR_4_8_BETA2 to mozilla-1.9.1 in changeset a183291b4467: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a183291b4467 This should be the last NSPR 4.8 Beta before RTM.
Assignee: nobody → wtc
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1
I must do a bit of a WHACK!!! on this. There's no mention of why BETA2 was even needed. BETA1 seems to have totally busted the Linux nightly on which it was present (yesterday's). Thanks for the fix, but you should have added some doc here, too. I'll post something about "Linux users MUST get the hourly tinderbox" into Mozillazine's nightly builds thread.
Rick, Sorry about the unclear hg commit comments. I didn't know that BETA1 broke the Linux nightly, so BETA2 was not an attempt to fix that. BETA2 is simply the last Beta I planned before RTM. If BETA1 broke the Linux nightly, BETA2 will also break it because the changes between BETA1 and BETA2 are small. What's the problem with the Linux nightly?
USER ERROR. I apologize. In looking harder, I see that I mis-clicked the download-- and tried to run the x86_64 version in my 32-bit Linux OS. Sorry to have wasted your time-- I'll go fix my mozillazine post.
No problem. My excuse for writing short hg commit comments for these two NSPR updates is that they are supposed to be uneventful after being baked in mozilla-central for a long time.
Wan-Teh: we still on track to see the update tomorrow?
Yes, thanks for the reminder. I plan to push NSPR_4_8_RTM today.
I pushed NSPR_4_8_RTM to mozilla-1.9.1 in changeset 9fef988ed375: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9fef988ed375 I pushed NSPR_4_8_RTM to mozilla-central in changeset 48dd4339ea86: http://hg.mozilla.org/mozilla-central/rev/48dd4339ea86
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.