Firefox 3.5 Beta 4 Schedule

1 view
Skip to first unread message

Mike Beltzner

unread,
Mar 6, 2009, 6:01:23 PM3/6/09
to mozilla.dev.planning group, dev-pl...@lists.mozilla.org, dev-apps-firefox List
reply-to: dev-pl...@lists.mozilla.org
follow-up-to: mozilla.dev.planning

Now that we've tagged the mozilla-1.9.1 branch in order to build Beta
3, it's time to look at a schedule for Beta 4. We'll want to have
several weeks of Beta 3 coverage to ensure that we're getting testing
and feedback from the breadth of the web, as well as to ensure that
we've got enough time to drive our list of approximately 100 blockers
down to close to zero.

As of yesterday, the mozilla-1.9.1 branch is re-open to:
- string changes
- patches marked with approval1.9.1+
- patches on bugs that are marked as blocking1.9.1+ or blocking-
firefox3.1+

Developers with patches for the 44 blockers that are FIXED on mozilla-
central but not yet on trunk should set about landing those patches on
mozilla-1.9.1 immediately:

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FIX%20-!fixed1.9.1%2Cverified1.9.1%20flag%3Ablocking1.9.1%2B,blocking-firefox3.1%2B

I'm proposing the following schedule; for now this is an estimate,
we'll discuss & finalize it at next Tuesday's development meeting:

string freeze: Thursday, March 19th at 11:59pm PDT (note: PDT starts
March 8th!)
code freeze: Monday, April 6th at noon PDT
qa start: Tuesday, April 7th at 9am PDT
release: Tuesday, April 14th, afternoon PDT

cheers,
mike

Axel Hecht

unread,
Mar 6, 2009, 6:45:18 PM3/6/09
to
On 07.03.2009 0:01 Uhr, Mike Beltzner wrote:
> reply-to: dev-pl...@lists.mozilla.org
> follow-up-to: mozilla.dev.planning
>
> Now that we've tagged the mozilla-1.9.1 branch in order to build Beta 3,
> it's time to look at a schedule for Beta 4. We'll want to have several
> weeks of Beta 3 coverage to ensure that we're getting testing and
> feedback from the breadth of the web, as well as to ensure that we've
> got enough time to drive our list of approximately 100 blockers down to
> close to zero.
>
> As of yesterday, the mozilla-1.9.1 branch is re-open to:
> - string changes
> - patches marked with approval1.9.1+
> - patches on bugs that are marked as blocking1.9.1+ or blocking-firefox3.1+
>
> Developers with patches for the 44 blockers that are FIXED on
> mozilla-central but not yet on trunk should set about landing those

> patches on mozilla-1.9.1 immediately:
>
> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FIX%20-!fixed1.9.1%2Cverified1.9.1%20flag%3Ablocking1.9.1%2B,blocking-firefox3.1%2B
>
>
> I'm proposing the following schedule; for now this is an estimate, we'll
> discuss & finalize it at next Tuesday's development meeting:
>
> string freeze: Thursday, March 19th at 11:59pm PDT (note: PDT starts
> March 8th!)
> code freeze: Monday, April 6th at noon PDT
> qa start: Tuesday, April 7th at 9am PDT
> release: Tuesday, April 14th, afternoon PDT

I guess we should make the "string changes" bit more clear, even though
it has been said often enough in theory.

We're string frozen, but as we did in previous releases, we're realistic
enough to take a limited amount of breakages of that string freeze.
We're accepting the landing of those 'til March 19th.

Clearly, beltzner did not intend to couple his three items together with
an OR.

As a general guideline, any bit of change to a file in a locales/en-US
directory in the mozilla-1.9.1 repository is a string change. If you
think it's not, ask. CC me on the bug, explain why you think it's not.
It's much better to do that upfront than to have the localizers poke me
if I think you broke the rules. Which is what happens if I didn't
comment on your landing before, frankly. This is not exact science, so
instead of making up static rules, just ask.

If you do have a patch, make sure it shows up on
<https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&classification=Client+Software&classification=Components&product=Core&product=Firefox&product=Toolkit&chfieldto=Now&field0-0-0=resolution&type0-0-0=changedafter&value0-0-0=2009-01-01&field0-0-1=resolution&type0-0-1=nowordssubstr&value0-0-1=FIXED+DUPLICATE+INVALID+WONTFIX+WORKSFORME+INCOMPLETE&field1-0-0=keywords&type1-0-0=substring&value1-0-0=late-l10n&field1-1-0=keywords&type1-1-0=nowords&value1-1-0=verified1.9.1+fixed1.9.1>
which, if all your 1.9.1 keywords are cool, should just require adding a
late-l10n keyword.

Thanks

Axel

Reply all
Reply to author
Forward
0 new messages