Just a friendly reminder that tomorrow is our code freeze for RC2. As
of this writing the only approved patch waiting to land is:
https://bugzilla.mozilla.org/show_bug.cgi?id=354670
If you have any issues that you believe are show stoppers for the
release please let us know asap.
Mike
as of now, the l10n repository is locked down, zero Kelvin.
I'd like to ask folks in mail/calendar to not check-in while we're doing
RC2 as well, it just makes our life easier.
For those locales that have missed 2.0, we don't exactly know when we'll
open up the branch for you, but we do know that we want to do that
rather sooner than later. I guess we'll do so on short notice as soon as
we feel that we don't have to respin l10n for 2.0.
I'll open up the tree for mail/calendar after RC2 is built and tagged.
Thanks to everyone.
I do see a plethora of work coming up for build and QA :-). Oh, and
justin is looking for additional mirror resources.
Axel
Bug 354711 is a crash that was introduced by one of the recent security fixes.
I believe it can only be triggered from extensions (and other chrome/C++ code),
though, so not sure whether we should block the release for it.
-Boris
https://bugzilla.mozilla.org/show_bug.cgi?id=313400 didn't get
approval for 1.8.1, but maybe it can be reconsidered?
It is numer 30 on the firefox2 branch crash list, so it's not really a
topcrasher, but the patch is almost a year in trunk and seems very
safe to me.
Regards,
Martijn
We're mostly code frozen, but holding off on spinning builds to get a few last minute regressions and l10n help fixes.
Triage will be at 11am PDT, and then we'll post back here.
cheers,
mike
Hi Folks,
https://bugzilla.mozilla.org/show_bug.cgi?id=354670
Mike
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
https://bugzilla.mozilla.org/show_bug.cgi?id=346642
- JS de-compilation for de-structuring assignment
- patch up for review, need to get a solid assessment of risk/
reward here
https://bugzilla.mozilla.org/show_bug.cgi?id=354772
- need to get an understanding of impact on the 1.5.0.7 -> 2.0 upgrade
https://bugzilla.mozilla.org/show_bug.cgi?id=354815
- waiting for confirmation from timr that we can add gu-IN/w32 into
shipped locales
https://bugzilla.mozilla.org/show_bug.cgi?id=354865
- gavin's found the patch that causes this regression, need dbaron/
bz to help us understand why that is, and what the effect of backing
that patch out is
https://bugzilla.mozilla.org/show_bug.cgi?id=313400
- been on trunk for a while, seems like a safe fix, will likely
approve
https://bugzilla.mozilla.org/show_bug.cgi?id=351897
- kai engert tells us this is the right thing to do for OSCP, well
tested, will likely approve.
We'll be holding another triage session this afternoon, probably
around 4:30 PDT. More details as they come in.
cheers,
mike
On 29-Sep-06, at 10:11 AM, Mike Beltzner wrote:
> All,
>
> We're mostly code frozen, but holding off on spinning builds to get
> a few last minute regressions and l10n help fixes.
>
> Triage will be at 11am PDT, and then we'll post back here.
>
> cheers,
> mike
> -----Original Message-----
> From: Mike Schroepfer <sch...@mozilla.com>
> Date: Thu, 28 Sep 2006 22:30:06
> To:dev-pl...@lists.mozilla.org
> Subject: Reminder - FF2 RC2 Code Freeze 9/29/2006 at 9AM PDT
>
>Hi,
>
>as of now, the l10n repository is locked down, zero Kelvin.
>
>I'd like to ask folks in mail/calendar to not check-in while we're doing
>RC2 as well, it just makes our life easier.
Pike, we (Sunbird/Lightning team) have a release coming up, that is at
least as important to us as Firefox 2 is important for you and the
Mozilla Corporation.
And since we'd like to tag the /l10n repository on October 03 for the 1.8
branch (from which we'll release Lightning, Sunbird will come from its
own branch which originates from the 2006-09-27 trunk), this is really a
major showstopper for us.
I understand your desire to keep everything nice and tidy, but I fail to
see how checkins to /l10n/ab-CD/calendar could somehow affect FF2.
Therefore I would really appreciate it, if you could revise your
statement above.
Thanks in advance
Simon
--
Sunbird/Lightning Website Maintainer:
http://www.mozilla.org/projects/calendar
Sunbird/Calendar blog: http://weblogs.mozillazine.org/calendar
We have 40 localizations to ship, and we need to lock them down. There
are three parts to this, one is, we have to lock down all of them at
once. Everything else is just technically not feasible. The next one is
to send out the message of the lockdown, and this is in part a tooling
problem. We just don't have one tinderbox for l10n, where we could post
a tree rules message. I post that to the main l10n tinderbox, but that's
of very limited use to localizers, so that message is partly cosmetic.
Nor do all localization teams follow the posts in .l10n as eagerly as we
would hope, or just don't get the real life implications of what is
written. The third part is to actually watch that that happens. Sadly,
bonsai-l10n sucks at that. Both because it doesn't show branch-only
check-ins, and because there's no way to reasonably filter.
Unfortunately, folks do see other check-ins, and then interpret the
stuff they see in a way that makes it close to impossible to freeze just
parts of the l10n rep. At least not if you really want it frozen. The
fact that all our products depend on common parts doesn't help.
Thus, when it comes down to it, I need to freeze the complete branch for
a Firefox release. At least as long as we're evaluating which version on
that branch to build. The scheme of freezing the tree and then picking
some not-so-bad timestamp between a bunch of accidental and
non-accidental non-approved check-ins to tag l10n is just not working right.
I'm sorry if our problems to actually get Firefox RC2 built have a
negative impact on the Calendar release, but I don't see a way around that.
Axel
https://bugzilla.mozilla.org/show_bug.cgi?id=346642
- JS de-compilation for de-structuring assignment
- Patch is on trunk. Our understanding is we need to take this
otherwise folks to run into obvious probs with new feature. Expecting
it to land on branch this weekend.
https://bugzilla.mozilla.org/show_bug.cgi?id=354772
- Need better understanding of what is going on here
https://bugzilla.mozilla.org/show_bug.cgi?id=354865
- We've got what looks like a safe fix on trunk. Just need to confirm
if we want it on branch
https://bugzilla.mozilla.org/show_bug.cgi?id=313400
- Given it impacts Typo3 and it has been on trunk for a very long time
we have approved.
https://bugzilla.mozilla.org/show_bug.cgi?id=349680
- This just came in - need to figure out what the right approach is
Given most of this stuff is reasonably well understood we should be able
wrap them up this weekend.
Schrep
Mike Beltzner wrote:
> OK, triage done. We approved a few updates to the feed preview feature,
> and we continue to be in the process of freezing (I need to come up with
> new terms for state of code-frozenness for everyone's entertainment).
> Here's the bugs we're still blocked on / need decisions for:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=346642
>
> - JS de-compilation for de-structuring assignment
> - patch up for review, need to get a solid assessment of risk/reward here
Thanks to lot of hard work yesterday and today all the JS and crash
fixes have landed. All that is currently left is:
https://bugzilla.mozilla.org/show_bug.cgi?id=354772
- SU issue which affect 1.5.0.7 as well. Need to verify that a
backout will fix the issue
https://bugzilla.mozilla.org/show_bug.cgi?id=349680
- Need to figure out what the right approach is
Once we resolve both of these we'll spin the RC2.
Best,
Schrep
schrep is OK with it, so we're reopening the MOZILLA_1_8_BRANCH for
check-ins that affect Thunderbird or Calendar only, by source location.
Firefox and Toolkit remain locked down.
Thank you for your cooperation
Axel
Axel Hecht wrote:
> schrep is OK with it, so we're reopening the MOZILLA_1_8_BRANCH for
> check-ins that affect Thunderbird or Calendar only, by source location.
Thanks for your willingness to be flexible about all this stuff.
Dan