Mozilla 1.3 status update

Asa Dotzler

unread,

Feb 12, 2003, 9:32:56 PM2/12/03

to

It's Wednesday afternoon and we've got lots of bugs. 1.3beta has been
going out to the masses and TalkBack data is starting to flow and
already points to some new crashers.

Drivers have been going through the nominations (see
news://news.mozilla.org:119/au0qi8$dr...@ripley.netscape.com ) and
approval requests.If you find a bug that is nasty enough to block the
release of 1.3, please set the blocking1.3? flag in the bug. If you've
got a fix that's fully reviewed and you think it's critical to a
successful release of 1.3, please set the approval1.3? flag in the patch.

So far we've approved 32 patches and just over half of them have landed
<http://bugzilla.mozilla.org/buglist.cgi?bug_id=,192192,191749,121998,148043,122282,192701,192718,112264,192486,186129,192336,191965,114505,186133,191127,192712,154931,188051,192847,192479,192074,192794,192805,189079,177972,192322,183331,191758,163744,186515,192294,159796>

The blocker list is at 24 bugs (2 fixed)
<http://bugzilla.mozilla.org/buglist.cgi?bug_id=,186132,179856,160602,140852,190860,192207,192577,181293,192124,190106,191817,182107,190484,192837,173369,191339,189965,191684,192294,191215,192043,170539,192984,192917>
and of those 7 are crashers, 2 are dataloss, about a dozen are major
losses of functionality or correctness and 1 bug is API documentation.

This is a pretty big list and we need to get it knocked down quickly to
get branched and open the trunk to 1.4alpha development. If you own one
of the blocking bugs please keep drivers up to date either in the bug or
with email to dri...@mozilla.org If you own one of the approved to
land bugs please do so at the first open tree. The sooner we get these
changes in the sooner we can verify the fix or root out any regressions.
Thanks.

--Asa

Asa Dotzler

unread,

Feb 14, 2003, 2:46:48 AM2/14/03

to

Thursday evening and drivers have approved 56 patches for 1.3 final and
36 of them have landed
<http://bugzilla.mozilla.org/buglist.cgi?bug_id=,192192,191749,121998,148043,122282,192701,192336,191965,186133,166504,154931,189193,188051,192847,192074,192805,189079,177972,192322,186515,159796,142148,82547,192479,186129,191127,112264,114505,191758,192794,190860,191794,191967,191135,193062,192299,185790,192828,163744,192291,192712,191392,183331,193078,189775,190555,192213,192486,191413,189965,174713,192718,185889,193054,192294,189494>

The blocker list is at 31 bugs (5 of them fixed)
<http://bugzilla.mozilla.org/buglist.cgi?bug_id=,186132,179856,192577,181293,191817,191339,170539,190484,192837,190860,182107,192043,192011,173369,160602,140852,192917,189832,192984,191684,190106,192207,112337,189965,191215,192124,193189,191715,192294,191835,193227>

Tinderbox should reflect the current blocker list but the query there,
being live, will take a bit longer to complete than the static lists
posted here. So if you're just a casual observer then these static lists
are for you. If you're active on the project then you can find the more
up-to-date information on tinderbox.

--Asa

Rick DeBau

unread,

Feb 15, 2003, 2:30:53 AM2/15/03

to

I think the one thing we're missing is regression testing. I've seen many
Mozilla releases introduce errors between beta and release canidate, and the
response was "no non-critical fixes until after it ships."
No, I don't have an answer for us at this point, but this is something that
software projects have to deal with, and I don't feel that Mozilla is doing it.
Each release MUST be better in terms of stability, performance, compliance, etc.

If there is a forum I can be pointed to for Mozilla project management, feel
free to flame me in that direction...

Thanks, Rick DeBay
http://www.gate.net/~casper/

In article <3E4B03D8...@mozilla.org>, Asa says...

Christian Biesinger

unread,

Feb 15, 2003, 12:35:17 PM2/15/03

to

Rick DeBau wrote:
> Each release MUST be better in terms of stability, performance, compliance, etc.

Why do you think so? Esp., do the Alpha releases have to better than
final releases?

Boris Zbarsky

unread,

Feb 16, 2003, 12:16:51 PM2/16/03

to

Lennier wrote:

> IMHO, I agree that all final releases should be better in all respects
> that the previous final releases.

Then we need to lengthen the period between final releases or make some
changes to the checkin policies (a la paper's suggestions), imo.

Peter Lairo

unread,

Feb 18, 2003, 6:24:32 AM2/18/03

to

The "in _all_ respects" part is probably taking it too far. If the
current final release is "more-better-than-worse" than the previous
final release, then we're making progress; and that should be happening
by default (unless we're not fixing any bugs and carelessly causing
regressions). :-\

The length between final releases seems too long already (to my
impatient, non-programming self ;) ).

--
Peter Lairo

--==--
"What comes to pass does so not so much because a few people want it to
happen, as because the mass of citizens abdicate their responsibility
and let things be." - Antonio Gramsci
--==--

Gervase Markham

unread,

Feb 19, 2003, 12:15:45 PM2/19/03

to

> All final releases, IMHO, should be a real improvement over the previous
> final release.

Do you also believe that "final releases" should appear at regular
intervals? Because holding both views has a significant impact on the
level of changes we can ever make to the code.

Gerv

CNolan

unread,

Feb 19, 2003, 1:32:34 PM2/19/03

to

RIGHT ON--Lennier

just an end user

Lennier wrote:

> On Tue, 18 Feb 2003 12:24:32 +0100, Peter Lairo wrote:
>
>
>>>>IMHO, I agree that all final releases should be better in all respects
>>>>that the previous final releases.

>

> All final releases, IMHO, should be a real improvement over the previous
> final release.
>

> In this I mean nothing that was working should be broken in the new final
> release, and should contain either USABLE new features, or genuine
> improvements to current features as would be perceived by end users, or
> genuine improvements to performance, footprint size, and usability.
>
> If a new feature means something gets broken, then that breakage should be
> fixed before the final release.
>
> Lennier
>

--
---...---

Registered Linux User #190812

CNolan

unread,

Feb 19, 2003, 1:36:32 PM2/19/03

to

In a word NO

That is M$ answer for progress.

There should be no "final release" of eny product until all that is
needed for this release is 'feature enhancment' and "minor" bug fixes.

still just a end user

>
>
> Do you also believe that "final releases" should appear at regular
> intervals?

> Gerv

Asa Dotzler

unread,

Feb 19, 2003, 9:43:42 PM2/19/03

to CNolan

CNolan wrote:
> RIGHT ON--Lennier
>
> just an end user
>

These are developer groups intended for developer discussion. Please
make advocacy and end user comments somewhere else (like the forums at
http://www.mozillazine.org )

If you're not a code contributr or a serious QA contributor then
n.p.m.seamonkey is not the place to be posting.

Thanks,

--Asa

Asa Dotzler

unread,

Feb 19, 2003, 10:02:32 PM2/19/03

to

It's Wednesday evening and we're not branched for final yet but we're
making lots of good progress. We've identified several nasty regressions
from the 1.3beta (exactly what it's intended to do) and drivers have
been working with developers to get the blocker list knocked down.

Drivers have approved a total of 101 bugs for landing in the 1.3final
cycle
<http://bugzilla.mozilla.org/buglist.cgi?bug_id=,191749,148043,122282,192701,192336,191965,186133,154931,188051,192847,192074,177972,192322,186515,159796,192479,186129,191127,112264,114505,190860,191794,191967,191135,193062,192828,192291,192486,166504,192213,192299,185790,183331,192718,193227,193078,189079,169036,189832,174713,186510,193405,193054,188729,192478,193586,192805,191392,193719,192712,193637,193748,193081,193256,192794,144331,193710,191413,171128,192561,193393,163744,190555,189193,193267,140852,139396,193017,163998,189775,193763,191826,193593,193716,192281,191215,189965,192192,142148,121998,192294,82547,190960,188856,189494,193295,191758,191818,192768,193241,173369,192819,190362,193611,185690,126826,192124,186132,185889,193189,191996>
and 8 of them have not yet been landed so if you're the owner of any of
these
<http://bugzilla.mozilla.org/buglist.cgi?bug_id=,191749,169036,144331,191826,191818,192768,126826,186132>
bugs then please get it landed at the first available open tree.

There have been a total of 43 bugs flagged by drivers as blockers to 1.3
final
<http://bugzilla.mozilla.org/buglist.cgi?bug_id=,190860,182107,191339,193227,189832,192478,193586,191817,193081,140852,160602,83349,193017,192577,192984,191215,192808,189965,170539,192043,192294,190484,192917,193295,192768,192207,193241,173369,193689,193347,192589,179856,192124,192011,186132,193568,181293,191684,185889,193189,140995,174197,190106>
and of those 43, 22 have been resolved. That puts us as 21 open blockers
for 1.3
<http://bugzilla.mozilla.org/buglist.cgi?bug_id=,83349,140995,170539,174197,179856,181293,186132,190106,190484,191339,191684,192043,192207,192577,192589,192768,192917,192984,193347,193568,193689>
and of those 21, more than half have patches in progress, being reviewed
or ready to land.

We're always hesitant to branch with large unknowns but if we can get
the 14 or so bugs with patches in progress landed and get a handle
on/patches in progress for the remaining 7 or so bugs we'd be in pretty
good shape to branch and open the tree to 1.4alpha development.

If you own one of the already approved bugs, please land at the first
open tree opportunity and if you've got patches that are stalled at
review or super-review then let drivers know so we can get you some
help. If you own one of the handful of bugs on the blocking list that
doesn't have any forward movement please let drivers know what's going
on and how we can help.

--Asa

Michael Lefevre

unread,

Feb 20, 2003, 11:09:55 AM2/20/03

to

In article <b31g25$lc...@ripley.netscape.com>, Asa Dotzler wrote:
[snip]

> Drivers have approved a total of 101 bugs for landing in the 1.3final
> cycle

[snip]

> That puts us as 21 open blockers for 1.3

[snip]

>
> We're always hesitant to branch with large unknowns but if we can get
> the 14 or so bugs with patches in progress landed and get a handle
> on/patches in progress for the remaining 7 or so bugs we'd be in pretty
> good shape to branch and open the tree to 1.4alpha development.

[snip]

excuse me butting in to your update thread, but you're making this sound
a little dicey, IMHO... 101 patches and at least another 21 to go is
quite a lot for a "final" cycle. 1.3b introduced a lot of regressions
from 1.3a, and as 1.2 demonstrated, as soon as the branch happens, nearly
all the QA attention moves back to the trunk. so, if the branch happens
with stuff remaining, you'll have 110 patches that haven't been tested by
the world at large, and a further 20 or so that have only been tested by
a couple of people that are testing the branch...

I guess in the event that nasty bugs end up in 1.3 final, there could
always be a 1.3.1, but my vote (not that I have one) would be with
delaying the branch until things are in "release candidate" state.
(Actually, saying that, how about an early branch and a 1.3rc release, as
with 1.0? that would get testing on the branch and allow the work on the
trunk to start earlier... just a thought...)

--
Michael

Gervase Markham

unread,

Feb 20, 2003, 11:40:21 AM2/20/03

to

Lennier wrote:

> On Wed, 19 Feb 2003 17:15:45 +0000, Gervase Markham wrote:
>
>>>All final releases, IMHO, should be a real improvement over the
>>>previous final release.
>>
>>Do you also believe that "final releases" should appear at regular
>>intervals?
>

> Yes.

Right. By specifying these two things you have made it impossible to do
certain sorts of changes. Large changes which require several months of
work, with things not working very well during the change, could not be
done under this model, even if they produced a better product in the
long run.

You can't have both regular releases every X weeks _and_ every release
being an improvement over the previous ones if you want to retain the
flexibility to make major changes as necessary.

Gerv

Boris Zbarsky

unread,

Feb 20, 2003, 12:54:10 PM2/20/03

to

Lennier wrote:

> Mozilla is now very well on the way to being mature software

Well, core layout work is now becoming aimed at major reworking of some
things. You can call this "Gecko 2.0" work or whatever, but it does
_not_ belong in "mature software". There will be problems, there will
be regressions, etc.

So either work on layout stops, or we don't use your proposed system.

unread,

Feb 22, 2003, 2:41:42 PM2/22/03

to

RV wrote, On 03-02-22 15:49:

> Gervase Markham wrote:
>
> I agree with you Gerv. The problem I see is that people don't understand
> that 1.0x is the stable branch and that the 1.x trunk is the DEVELOPMENT
> side

It is a bit confusing. It seems to me that the 1.0.x branch *only*
contains stability and security fixes, and *no* new features. By this
reasoning, nothing new from the development branch will ever make it
into the 1.0.x branch. Perhaps some enlightenment would be useful. :-\
--
Regards,

Peter Lairo

-=-=-
Character is "Doing the Right Thing..." Even when "No One is Watching..."
-=-=-

RV

unread,

Feb 22, 2003, 3:39:03 PM2/22/03

to

Peter Lairo wrote:

> It is a bit confusing. It seems to me that the 1.0.x branch *only*
> contains stability and security fixes, and *no* new features. By this
> reasoning, nothing new from the development branch will ever make it
> into the 1.0.x branch. Perhaps some enlightenment would be useful. :-\

Mozilla can one day branch the development trunk at a particular
milestone and call that a stable branch. Lets say, for argument sake,
M1.5. Then additional stability fixes are added to that particular
Milestone. Of course they might decide not to branch for a stable
(production quality?) release until they reach M2.0. That's probably a
desicion made between Moz developers, outside contribuitors and
supporting ISVs)

In a close development system, you only see when companies release from
their stable branch, their development trunk stays invisible to users
until they decide to branch for a new stable release whether is a
decimal point release (0.x) or a full point release (x.0)

Peter Lairo

unread,

Feb 23, 2003, 1:01:15 PM2/23/03

to

RV wrote, On 03-02-22 21:39:

> Peter Lairo wrote:
>
>> It is a bit confusing. It seems to me that the 1.0.x branch *only*
>> contains stability and security fixes, and *no* new features. By this
>> reasoning, nothing new from the development branch will ever make it
>> into the 1.0.x branch. Perhaps some enlightenment would be useful. :-\
>
> Mozilla can one day branch the development trunk at a particular
> milestone and call that a stable branch.

Ah, so the existing stable branch is not added-to (e.g., new features)
from the dev branch, it is *completely replaced* by a new branch taken
from the dev branch!?

--
Regards,

unread,

Mar 6, 2003, 1:47:16 PM3/6/03

to

In article <b4837u$h1...@ripley.netscape.com>, Asa Dotzler wrote:
>
> We're down to just a few blockers
> http://bugzilla.mozilla.org/buglist.cgi?bug_id=,182117,192914,181293,194992
> and hope to have a release shortly.

[snip]

you missed bug 196115 out of that list...

> As soon as we get the remaining fixes landed I'll announce the first
> candidate builds and solicit as much testing as we can get. A post
> pointing to the candidate builds will show up here and hopefully
> mozillazine.org.

how about mozilla.org? or is that too much?

> When we've tested those builds and found no new
> problems, the release will happen.

[snip]

yay :)

--
Michael

RV

unread,

Mar 6, 2003, 8:00:38 PM3/6/03

to

Asa Dotzler wrote:
It looks like we may not get the
> fix for the gray toolbars problem on Mac :(

Is it possible to hold the Mac release a few extra days or a week .. or
is there any particular reason for releasing all versions simulteneously?

RV

David King

unread,

Mar 7, 2003, 12:03:31 PM3/7/03

to

In my book, that is the same as moving that particular bug to 1.4a,
especially as the root cause of the bug is not yet known.

Matthew Wilson

unread,

Mar 8, 2003, 10:22:47 AM3/8/03

to

This is probably the wrong place to bring this up, but there seems to
be a broken UI element in 1.3 beta,
http://bugzilla.mozilla.org/show_bug.cgi?id=185475.

Matthew Wilson

Asa Dotzler

unread,

Mar 8, 2003, 3:22:04 PM3/8/03

to

Asa Dotzler wrote:

> We're down to just a few blockers
> http://bugzilla.mozilla.org/buglist.cgi?bug_id=,182117,192914,181293,194992
> and hope to have a release shortly. A couple of the bugs have patches
> and are ready or nearly ready to land. It looks like we may not get the
> fix for the gray toolbars problem on Mac :(
>
> As soon as we get the remaining fixes landed I'll announce the first
> candidate builds and solicit as much testing as we can get. A post
> pointing to the candidate builds will show up here and hopefully
> mozillazine.org. When we've tested those builds and found no new
> problems, the release will happen.
>
> In the mean time, if you're not fixing one of these blocker bugs,
> testing the latest builds from
> http://komodo.mozilla.org/pub/mozilla/nightly/latest-1.3/ and nominating
> any new and nasty discoveries using the blocking1.3? flag is the best
> way to help get this release out the door.
>
> --Asa
>

We've been hard at work cleaning up the last of the blocking problems
with 1.3. Today we have our first set of candidate builds and are
looking to get as much usage/testing on these builds as we can. If you
want to help make Mozilla 1.3 the best release to date, please grab one
of the builds linked below, use it, abuse it, and let us know if you
find any nasty problems. To alert drivers to a bug that's bad enough to
block the 1.3 final release, find or file the bug and set the bug flag
"blocking1.3?" (this field lives just under and to the left of the Cc:
list).

If all goes well and nothing new and horrible is discovered then we
should see a 1.3 release real soon now. Thanks for your help in making
Mozilla rock!

Windows build:
http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-08-05-1.3/mozilla-win32-installer-sea.exe

Linux build:
http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-07-15-1.3/mozilla-i686-pc-linux-gnu-sea.tar.gz

Mac OS X build:
http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-08-05-1.3/mozilla-mac-MachO.dmg.gz

--Asa

Michael Lefevre

unread,

Mar 8, 2003, 10:27:31 PM3/8/03

to

In article <b4dius$h1...@ripley.netscape.com>, Asa Dotzler wrote:
>
> We've been hard at work cleaning up the last of the blocking problems
> with 1.3. Today we have our first set of candidate builds and are
> looking to get as much usage/testing on these builds as we can.

[snip]

um... what's going on with bug 194994? as far as I can see, you marked
it as a blocker a couple of days ago, and it's not fixed (it was marked
FIXED briefly, but that was just a mistake).

--
Michael

Asa Dotzler

unread,

Mar 11, 2003, 1:28:15 AM3/11/03

to

Asa Dotzler wrote:
> We've been hard at work cleaning up the last of the blocking problems
> with 1.3. Today we have our first set of candidate builds and are
> looking to get as much usage/testing on these builds as we can. If you
> want to help make Mozilla 1.3 the best release to date, please grab one
> of the builds linked below, use it, abuse it, and let us know if you
> find any nasty problems. To alert drivers to a bug that's bad enough to
> block the 1.3 final release, find or file the bug and set the bug flag
> "blocking1.3?" (this field lives just under and to the left of the Cc:
> list).
> If all goes well and nothing new and horrible is discovered then we
> should see a 1.3 release real soon now. Thanks for your help in making
> Mozilla rock!
> Windows build:
> http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-08-05-1.3/mozilla-win32-installer-sea.exe
> Linux build:
> http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-07-15-1.3/mozilla-i686-pc-linux-gnu-sea.tar.gz
> Mac OS X build:
> http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-08-05-1.3/mozilla-mac-MachO.dmg.gz
>
> --Asa

We've taken a few more fixes and have another round of candidate builds.
New to these builds are several important fixes that could use lots of
testing.

The first is the fix for the nasty Mac gray toolbars problem that's been
plaguing some Mac users throughout the 1.3 cycles. If you were
experiencing this bug,
http://bugzilla.mozilla.org/show_bug.cgi?id=181293 please get the latest
1.3 candidate and let us know if you see further problems.

The second important fix is for "settimeout and setinterval not being
killed for iframes" bug
http://bugzilla.mozilla.org/show_bug.cgi?id=194994. This problem should
be fixed in the latest 1.3 builds but we need lots of testing of any and
all sites that use iframes to make sure nothing regressed.

In addition to those fixes, we also took patches for a few additional
bugs http://bugzilla.mozilla.org/buglist.cgi?bug_id=191974,194636,186257

As with the previous candidate builds, please use them and abuse them
and if you find any new problems file and nominate bugs with the
blocking1.3? flag.

Get the latest 1.3 candidate builds for

Linux:
http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-10-16-1.3/mozilla-i686-pc-linux-gnu-sea.tar.gz

Windows:
http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-10-17-1.3/mozilla-win32-installer-sea.exe

Mac:
http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-10-16-1.3/mozilla-mac-MachO.dmg.gz

and let us know whether it's 1.3 or not. Thanks for your help in making
Mozilla rock!

--Asa

Asa Dotzler

unread,

Mar 13, 2003, 5:05:14 PM3/13/03

to Asa Dotzler

Asa Dotzler wrote:

> Get the latest 1.3 candidate builds for
>
> Linux:
> http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-10-16-1.3/mozilla-i686-pc-linux-gnu-sea.tar.gz
>
>
> Windows:
> http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-10-17-1.3/mozilla-win32-installer-sea.exe
>
>
> Mac:
> http://ftp.mozilla.org/pub/mozilla/nightly/2003-03-10-16-1.3/mozilla-mac-MachO.dmg.gz
>
>
> and let us know whether it's 1.3 or not. Thanks for your help in making
> Mozilla rock!
>
> --Asa
>

It's done.

--Asa