Scheduling a trunk alpha

1 view
Skip to first unread message

Boris Zbarsky

unread,
Apr 11, 2006, 11:59:10 AM4/11/06
to
[Re-posting to right groups now]

Now that we've convinced people that FF 3 alpha is not out yet, let's figure out
when we _do_ plan to have a trunk alpha. The 1.8 branch branched on August 12,
2005; tomorrow it will be 8 months since that day. That's 8 months of trunk
development already; for comparison, by this point in the 1.8 Gecko cycle we had
already done the 1.8a5 release. Granted, the alphas weren't getting much
testing because of all the effort focused on Aviary, but we _did_ see a spike in
useful bug reports around each alpha being released.

I'm not sure what the thinking is about checkpointing trunk and calling it an
alpha and what the build team costs of doing an alpha release are, but I can
understand us not wanting to ship an alpha quite yet. At the same time, we've
made some pretty big changes (DOM event dispatch, frame display lists, 2/3 of
cairo) that could use testing.

We probably shouldn't ship an alpha until we turn on cairo by default on Mac.
But after that (hopefully soon?) point, what else do we need or want to wait
for? What other large projects are scheduled for 1.9 at this point? I can
think of reflow branch, view removal, widget removal, nsTextFrame rewrite, gfx
removal off the top of my head. Do we want all those done before we ship an
alpha? Or some subset of those? Are we OK with landing some of these after the
first alpha (and do we plan to have multiple alpha releases)? Are there things
I'm forgetting?

One last note: naming. I have no particular yen to have this be named "Firefox
3 Alpha 1". Let's make up a codename if we don't have one yet and ship this as
"Codename Developer Preview 1" or something. Make it clear that this is
pre-alpha (not all large features done) and list the specific large changes we
made that we'd like testing from web developers on...

One last note. As I recall, IE7 made "releases" similar to this "developer
preview" thing I'm suggesting -- before they ever got to beta they were doing
random development snapshots every so often. I realize we do that every day,
but that regularity itself means there's not as much "cool" factor to it as a
"finally, something they've let us have a glimpse at" thing like IE7 snapshots.
I wonder whether we could get a bigger testing audience with something that we
not only put on the FTP server but also mention on some blogs, the mozilla.org
web site (NOT mozilla.com), etc.

Thoughts?

-Boris

schiller

unread,
Apr 11, 2006, 12:52:58 PM4/11/06
to
Isn't the codename for Firefox 3 "minefield"? At least, that's what
the nightly trunk builds are called starting 04-11. "Mozilla Minefield
Pre-Alpha Developer Preview 1" sounds a little scary though... ;)

Boris Zbarsky

unread,
Apr 11, 2006, 1:34:31 PM4/11/06
to
schiller wrote:
> Isn't the codename for Firefox 3 "minefield"? At least, that's what
> the nightly trunk builds are called starting 04-11.

I was under the impression that we were planning to use "minefield" for all
trunk stuff from here on out (including Gecko 1.10 work after we ship 1.9, etc).

> "Mozilla Minefield Pre-Alpha Developer Preview 1" sounds a little scary though... ;)

Also not really expressive of what it is, if "minefield" is to be used
post-Gecko-1.9.

-Boris

Philip Chee

unread,
Apr 11, 2006, 2:35:14 PM4/11/06
to

How about:
"Mozilla Eats Babies for Lunch Pre-Pre-Alpha Developer Preview 0.0.0.1"

Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]If a program is useful, it must be changed.
* TagZilla 0.059

schiller

unread,
Apr 11, 2006, 3:01:27 PM4/11/06
to
> I was under the impression that we were planning to use "minefield" for all
> trunk stuff from here on out (including Gecko 1.10 work after we ship 1.9, etc).

Makes sense, actually...

Robert O'Callahan

unread,
Apr 11, 2006, 5:30:09 PM4/11/06
to
Boris Zbarsky wrote:
> I'm not sure what the thinking is about checkpointing trunk and calling
> it an alpha and what the build team costs of doing an alpha release are,
> but I can understand us not wanting to ship an alpha quite yet. At the
> same time, we've made some pretty big changes (DOM event dispatch, frame
> display lists, 2/3 of cairo) that could use testing.
>
> We probably shouldn't ship an alpha until we turn on cairo by default on
> Mac. But after that (hopefully soon?) point, what else do we need or
> want to wait for? What other large projects are scheduled for 1.9 at
> this point? I can think of reflow branch, view removal, widget removal,
> nsTextFrame rewrite, gfx removal off the top of my head. Do we want all
> those done before we ship an alpha? Or some subset of those? Are we OK
> with landing some of these after the first alpha (and do we plan to have
> multiple alpha releases)? Are there things I'm forgetting?

I think we should ship an alpha1 once we have cairo on on all platforms
and have sorted out the absolute killer issues. Hopefully we can do this
within a month?

We're going to have to ship another alpha after the reflow branch lands,
whenever that is. Hopefully that will be in time for alpha2. Probably by
then my widget changes and nsTextFrame will be in too ... this is at
least a few months away.

gfx removal is not a big issue IMHO.

Rob

Benjamin Smedberg

unread,
Apr 11, 2006, 5:28:59 PM4/11/06
to
Robert O'Callahan wrote:

> We're going to have to ship another alpha after the reflow branch lands,
> whenever that is. Hopefully that will be in time for alpha2. Probably by
> then my widget changes and nsTextFrame will be in too ... this is at
> least a few months away.

At which point we should also be able to base Firefox on XULRunner. The
remaining pieces of that work are mostly gated on release engineering and
some prerequisite installer work that robstrong is doing for FF2.

--BDS

Robert O'Callahan

unread,
Apr 11, 2006, 5:55:00 PM4/11/06
to

That will be excellent!

Rob

Chris Hofmann

unread,
Apr 11, 2006, 5:46:42 PM4/11/06
to Robert O'Callahan, dev-pl...@lists.mozilla.org
Robert O'Callahan wrote:
Boris Zbarsky wrote:
  
I'm not sure what the thinking is about checkpointing trunk and calling
it an alpha and what the build team costs of doing an alpha release are,
but I can understand us not wanting to ship an alpha quite yet.  At the
same time, we've made some pretty big changes (DOM event dispatch, frame
display lists, 2/3 of cairo) that could use testing.

We probably shouldn't ship an alpha until we turn on cairo by default on
Mac. But after that (hopefully soon?) point, what else do we need or
want to wait for?  What other large projects are scheduled for 1.9 at
this point?  I can think of reflow branch, view removal, widget removal,
nsTextFrame rewrite, gfx removal off the top of my head.  Do we want all
those done before we ship an alpha?  Or some subset of those?  Are we OK
with landing some of these after the first alpha (and do we plan to have
multiple alpha releases)?  Are there things I'm forgetting?
    
I think we should ship an alpha1 once we have cairo on on all platforms
and have sorted out the absolute killer issues. Hopefully we can do this
within a month?
  

There are about 77 new bugs filed with the regression keyword in the last 6 weeks.  Many owned by nobody.
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=anywords&keywords =regression&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2006-03-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

About 12 or these have some kind of  1.9a1  nomination or blocker flag
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keyword s_type=anywords&keywords=regression&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2006-03-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=blocking1.9a1

One step is make sure we get fully loaded nomination and blocker list by going through the regression and other lists of bug that could be important to getting good feedback on the alpha.

68 bugs are on the blocker/nomination list right now, with many of these looking like regressions, but from longer than 6 weeks ago, and almost 1/2 owned by nobody.   I'm guessing there is more work to be done to build a good list before the number starts going down.
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=anywords&keywords=regressi on&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=blocking1.9a1

A month seems optimistic to  figure out any other landing plans and get a good understanding of where things stand with current trunk builds, but it might be doable if we got several people going on heavy testing, nomination and triage work

chris h.
We're going to have to ship another alpha after the reflow branch lands,
whenever that is. Hopefully that will be in time for alpha2. Probably by
then my widget changes and nsTextFrame will be in too ... this is at
least a few months away.

gfx removal is not a big issue IMHO.

Rob
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
  

Boris Zbarsky

unread,
Apr 11, 2006, 6:06:07 PM4/11/06
to
Robert O'Callahan wrote:
> I think we should ship an alpha1 once we have cairo on on all platforms
> and have sorted out the absolute killer issues. Hopefully we can do this
> within a month?

Shipping then is what I was after, yes. I'd really like to hear from vlad, pav,
and anyone else who might know what the state of cairo on Mac is. If we can get
that on in the next two weeks and start working on the outstanding major issues,
I think doing this within a month is possible.

Note that doing all this also needs some build team support (because we really
do need to set up cairo and non-cairo perf tests across all platforms, etc). So
we're somewhat gated by our security releases here. :(

> gfx removal is not a big issue IMHO.

As I see it, it's something with a certain amount of regression likelihood as
APIs impedance-match in the move from gfx to thebes; both in terms of
performance and in terms of functionality (silly things like different arg
orders for functions that do similar things or whatnot). But I have to admit
that I haven't looked very hard at the thebes API, so maybe I'm being paranoid. ;)

-Boris

Boris Zbarsky

unread,
Apr 11, 2006, 6:09:23 PM4/11/06
to
Chris Hofmann wrote:
> There are about 77 new bugs filed with the regression keyword in the
> last 6 weeks. Many owned by nobody.
...

> About 12 or these have some kind of 1.9a1 nomination or blocker flag

I've been setting this on various regressions I run into...

What I think I'd really like is to be able to set the following flags today:

blocking1.9a1?
blocking1.9a2?
blocking1.9b1?
blocking1.9?

In terms of when we want to be sure that the bugs get fixed by... I know I've
been marking things that are really beta blockers in my mind as alpha blockers
just because that's all I can do with them. But maybe it's just me and we
shouldn't actually have all those flags yet and keep using the alpha bucket with
retriaging later on?

> 68 bugs are on the blocker/nomination list right now, with many of these
> looking like regressions, but from longer than 6 weeks ago

Right. Trunk's been open for 8 months, like I said...

-Boris

Robert O'Callahan

unread,
Apr 11, 2006, 7:07:41 PM4/11/06
to
Boris Zbarsky wrote:
> As I see it, it's something with a certain amount of regression
> likelihood as APIs impedance-match in the move from gfx to thebes; both
> in terms of performance and in terms of functionality (silly things like
> different arg orders for functions that do similar things or whatnot).

gfx removal (by which I think you mean switching code over from calling
the Thebes nsIRenderingContext to calling Thebes directly, possibly with
some related changes) is very unlikely to reduce performance. There
could be some regressions, but compared to stuff like reflow branch or
rewriting nsTextFrame, it seems small potatoes...

Rob

Vladimir Vukicevic

unread,
Apr 11, 2006, 6:46:18 PM4/11/06
to
Cairo on the Mac is being blocked by Cocoa widgets on the mac, which
should get added to your list of "big changes". I'm not sure at this
point what the status of that is; I'll be working on the cairo-specific
issues again shortly (mainly font selection and text rendering in an
ATSUI world).

As for removing gfx, it depends on what you mean -- if you mean
removing gfx/src/gtk, windows, mac, etc., then sure, that can be done.
If you mean removing the gfx interfaces entirely, that simply won't
happen before alpha1 -- it might not even happen before Fx3 -- because
it would mean rewriting all the code that uses nsIRenderingContext
right now to do things somewhat differently. I think we're at a point
where we can start doing that, but noone's signed up for it yet (I can
do some of it, but I have some other things to finish first). I think
we may carry around the nsIRenderingContext compat layer at least
through Fx3 at this point.

- Vlad

Chris Hofmann

unread,
Apr 11, 2006, 6:57:27 PM4/11/06
to Boris Zbarsky, dev-pl...@lists.mozilla.org
Boris Zbarsky wrote:
>
>
> I've been setting this on various regressions I run into...
>
> What I think I'd really like is to be able to set the following flags
> today:
>
> blocking1.9a1?
> blocking1.9a2?
Marcia added a2 as another bucket to throw things in for now.
> blocking1.9b1?
> blocking1.9?
>
I guess if we knew that this is what the rest of the milestone schedule
looked like we could set those up as well.

Do we agreed that that is what the backend of the milestone schedule
looks like for getting to 1.9 final? I think getting a1 and a2
milestones sorted out and triaged would tell us if we are on the path to
having the next milestone be b1 or possibly needing an a3...


> I

Peter van der Woude

unread,
Apr 11, 2006, 7:00:57 PM4/11/06
to
Boris Zbarsky wrote:
> 68 bugs are on the blocker/nomination list right now, with many of these
> looking like regressions, but from longer than 6 weeks ago

Right. Trunk's been open for 8 months, like I said...

I can't speak for all of the guys testing trunk since we branched but I
have a feeling that most testers are really waiting with nominating
?1.9a untill it's clear what 1.9a is supposed to look like (/contain).
We've had so many regressions from various larger changes that
not_frequently_crashing feels good enough.

Besides that, a lot of the work is simultaniously done for branch (like
Places).
Why should we nominate ?1.9a if it's a bug that must_be_fixed for FF2.0
anyway (and therefore has to land on trunk first) ?

A crash should be nominated and likewise a bug that drastically reduces
accessibility or usebility.. but after that.. I kind of feel lost (and
I'm sure I'm not the only one).

Boris Zbarsky

unread,
Apr 11, 2006, 7:52:19 PM4/11/06
to
Vladimir Vukicevic wrote:
> Cairo on the Mac is being blocked by Cocoa widgets on the mac, which
> should get added to your list of "big changes".

OK. So the current list of pending big changes (and their status when I
understand it) looks like:

reflow branch (status: tables being worked on, forms to be done)
view removal
widget removal
Firefox on XULRunner (status: needs release engineering and installer work)
Cocoa widgets
Cairo on the mac (status: waiting on cocoa widgets)
Coordinate system improvements (status: waiting on cairo)
nsTextFrame rewrite (status: waiting on cairo for all platforms?)

I feel like someone else mentioned something else but I'm forgetting it.... We
should probably wiki this list.

> I'm not sure at this point what the status of that is;

OK. Who would? Josh?

> As for removing gfx, it depends on what you mean -- if you mean
> removing gfx/src/gtk, windows, mac, etc., then sure, that can be done.
> If you mean removing the gfx interfaces entirely

I meant removal of the gfx interfaces yeah.

> that simply won't happen before alpha1

That was more or less what I thought, yeah.

> it might not even happen before Fx3

OK. It wasn't clear to me whether that was a "must have" for Fx3. I've removed
it from my list for the time being, since it sounds like it can happen
piecemeal instead of in a huge landing.

> (I can do some of it, but I have some other things to finish first)

Given the "waiting on" statuses above, time is probably better spent on getting
cairo on for all platforms, yeah.

Especially if roc is right and the gfx stuff can happen with relative safety (eg
in a beta cycle).

Thanks for the info!

-Boris

Boris Zbarsky

unread,
Apr 11, 2006, 7:55:03 PM4/11/06
to
Chris Hofmann wrote:
> Do we agreed that that is what the backend of the milestone schedule
> looks like for getting to 1.9 final? I think getting a1 and a2
> milestones sorted out and triaged would tell us if we are on the path to
> having the next milestone be b1 or possibly needing an a3...

That makes some sense to me.

-Boris

Mike Beltzner

unread,
Apr 11, 2006, 7:58:42 PM4/11/06
to Boris Zbarsky, dev-pl...@lists.mozilla.org
> when we _do_ plan to have a trunk alpha. The 1.8 branch branched on

I'm not sure what it means to release a trunk alpha. Is that simply a
date towards which we work to have a reasonably stable state in the
codebase? Since Firefox 3 is to be based on Gecko 1.9, is the idea
that this would be equivalent to a release of Firefox 3 Alpha 1? As
I'm often reminded, our codebase contains more than just Firefox, and
I'm assuming we'd want people to be testing the platform, not just the
Firefox product based on that platform. Also, I'm not sure that you
want to tie the trunk release schedule into the Firefox 3 product
release schedule ...

cheers,
mike

--

[ mike beltzner / user experience lead / mozilla corporation ]

Axel Hecht

unread,
Apr 11, 2006, 8:24:36 PM4/11/06
to

My gut feeling would be that it's more important to separate a1 and b1
than a1 and a2 at the current stage, so that one can decide "well, I'd
ship an alpha with this, but not a beta". Deciding if you'd ship an
alpha2 with it seems awkward to me.

Axel

Robert O'Callahan

unread,
Apr 11, 2006, 9:34:47 PM4/11/06
to
Vladimir Vukicevic wrote:
> As for removing gfx, it depends on what you mean -- if you mean
> removing gfx/src/gtk, windows, mac, etc., then sure, that can be done.
> If you mean removing the gfx interfaces entirely, that simply won't
> happen before alpha1 -- it might not even happen before Fx3 -- because
> it would mean rewriting all the code that uses nsIRenderingContext
> right now to do things somewhat differently. I think we're at a point
> where we can start doing that, but noone's signed up for it yet (I can
> do some of it, but I have some other things to finish first). I think
> we may carry around the nsIRenderingContext compat layer at least
> through Fx3 at this point.

Much of it is mostly-mechanical conversion. We have some good volunteers
who do that sort of thing.

Rob

Boris Zbarsky

unread,
Apr 11, 2006, 9:23:50 PM4/11/06
to
Mike Beltzner wrote:
> I'm not sure what it means to release a trunk alpha. Is that simply a
> date towards which we work to have a reasonably stable state in the
> codebase?

That's a good question. What I want is to release an alpha of Gecko 1.9. The
problem, of course, is that users don't use Gecko -- they use a browser or a
mail app or whatever. Back in the suite days, when development of front end and
back end was in sync (or rather, when there was not much front end development),
this just meant picking a time on trunk when nothing too obvious was broken,
closing the tree for a few days, making sure it passes smoketests, getting some
testing from mozillazine folks and QA for a day or two, tagging, shipping, and
reopening trunk.

At least as far as I can tell. Asa ought to be able to expand on this if you
ask him; he was a lot more involved with it than I was. ;)

> Since Firefox 3 is to be based on Gecko 1.9, is the idea
> that this would be equivalent to a release of Firefox 3 Alpha 1?

No. Firefox 3 Alpha 1 would be a release that has a good bit of the Firefox 3
UI work done too. Given that Firefox is currently working on Firefox 2, this
means that the day when that happens is a ways off.

> As I'm often reminded, our codebase contains more than just Firefox, and
> I'm assuming we'd want people to be testing the platform, not just the
> Firefox product based on that platform.

True, but testing "the platform" is hard for users without an app wrapping it
(whether that app be Firefox, Seamonkey, Epiphany, whatever).

> Also, I'm not sure that you want to tie the trunk release schedule into the Firefox 3 product
> release schedule ...

It's already tied to a certain extent -- we're not going to get the widespread
testing we need to call the trunk Gecko 1.9 done until we've done an alpha or
beta (or both!) of Firefox 3.

The goal, imo, of doing an alpha-type release of Gecko inside whatever the UI is
even though we're nowhere close to a Firefox 3 alpha is to catch various
regression issues so that when we _do_ ship the Firefox 3 alpha much later we
won't suddenly have 4 months worth of work of Gecko regression bugs filed... If
we make it clear that we want testing of the rendering engine, the group we're
interested in here (web developers) might give it a spin even without new UI stuff.

Given that trunk and 1.8 branch are keeping UI in sync with each other and that
branch UI is already considered alpha-quality, I don't foresee significant
issues in terms of UI breakage holding up whatever we decide to do on trunk, right?

-Boris

schiller

unread,
Apr 12, 2006, 12:33:00 AM4/12/06
to
Slightly selfish, er, tangential question here: Are there any
requirements on what delta SVG functionality will make it into Fx3? I
know there was a big piece outstanding for Declarative Animation/SMIL
(done by this guy:
http://brian.sol1.net/svg/2006/01/09/smil-animation-in-mozilla-report/)
but I'm not sure if this will make it for Fx3.

Is the idea something like "whatever the SVG guys can get done and
stable in time" or are there specific criteria, like "all of SVG 1.1"
:) ?

Mike Connor

unread,
Apr 12, 2006, 1:37:26 AM4/12/06
to
Boris Zbarsky wrote:
> One last note. As I recall, IE7 made "releases" similar to this
> "developer preview" thing I'm suggesting -- before they ever got to beta
> they were doing random development snapshots every so often. I realize
> we do that every day, but that regularity itself means there's not as
> much "cool" factor to it as a "finally, something they've let us have a
> glimpse at" thing like IE7 snapshots. I wonder whether we could get a
> bigger testing audience with something that we not only put on the FTP
> server but also mention on some blogs, the mozilla.org web site (NOT
> mozilla.com), etc.
>
> Thoughts?
>
> -Boris

I think that we're not ready for an alpha on trunk yet, but we do need a
way to hook people into a more-stable series of builds to get wider
testing. We have a really awesome capability within software update to
drive a channel for more frequent testing, that we can update as
frequently (or as intermittently) as we want, based on need/relative
stability.

Taking into account the following:

* Human cost of doing "real" releases (QA/build/release mgmt)
* The bunching effect around extended freezes (lots of landings jammed)
* The goal being to get web developer types, not users, using these builds
* The general usefulness of being able to update more frequently than
our traditional release process allows
* The lack of current smoketesting

it seems like there's a lot of potential wins in running an update
channel for trunk.

I'd like to suggest the following process:

* Create an update channel for known-good nightlies (i.e. mozilla-unstable)
* Push these builds for the web developer/webapps community via MDC and
other outlets
* Every second Thursday, close the tree and do smoketests on
Windows/Linux/Mac nightlies
* This timeframe can be stretched or shrunk around major landings (i.e.
it might take a month to put trunk back in working order after the
reflow branch landing, or we might miss a major bug in the smoketest,
and want to push another build quickly)
* If those builds pass, push those into the mozilla-update channel (full
MARs only, since those require the least testing)
* CVS tagging/source tarballs are not done for these releases, since
they're already pulled by date, and this is a lot of overhead.
* No UA/versioning/branding changes should be necessary, these are not
releases, they're just better-tested/theoretically safer builds

This should, positioned correctly, get us more trunk testers with less
effort, since the effort involved in keeping up is minimized, the
smoketested builds would mean a lot less pain for people in that
channel, and because of the vastly diminished overhead, we can fit
updates to the pace of development, instead of the other way around.

-- Mike

Axel Hecht

unread,
Apr 12, 2006, 4:54:18 AM4/12/06
to
Mike Connor wrote:
> Boris Zbarsky wrote:

<...>

> * Create an update channel for known-good nightlies (i.e. mozilla-unstable)
> * Push these builds for the web developer/webapps community via MDC and
> other outlets
> * Every second Thursday, close the tree and do smoketests on
> Windows/Linux/Mac nightlies

Every other week is a timeframe that is terribly hard to organize. I'd
expect that someone checks into the closed tree each and every time, and
closing the tree for one day every 14 sounds a bit intrusive to me.

I'd rather go for first whatever of the month.

> * This timeframe can be stretched or shrunk around major landings (i.e.
> it might take a month to put trunk back in working order after the
> reflow branch landing, or we might miss a major bug in the smoketest,
> and want to push another build quickly)
> * If those builds pass, push those into the mozilla-update channel (full
> MARs only, since those require the least testing)
> * CVS tagging/source tarballs are not done for these releases, since
> they're already pulled by date, and this is a lot of overhead.
> * No UA/versioning/branding changes should be necessary, these are not
> releases, they're just better-tested/theoretically safer builds
>
> This should, positioned correctly, get us more trunk testers with less
> effort, since the effort involved in keeping up is minimized, the
> smoketested builds would mean a lot less pain for people in that
> channel, and because of the vastly diminished overhead, we can fit
> updates to the pace of development, instead of the other way around.

Whichever timeframe we end up with, we should coordinate that with the
availability of builds to hunt down regression windows.

Axel

Robert Kaiser

unread,
Apr 12, 2006, 11:40:38 AM4/12/06
to
Boris Zbarsky schrieb:

> Vladimir Vukicevic wrote:
>> Cairo on the Mac is being blocked by Cocoa widgets on the mac, which
>> should get added to your list of "big changes".
>
> OK. So the current list of pending big changes (and their status when I
> understand it) looks like:
>
> reflow branch (status: tables being worked on, forms to be done)
> view removal
> widget removal
> Firefox on XULRunner (status: needs release engineering and installer work)
> Cocoa widgets
> Cairo on the mac (status: waiting on cocoa widgets)
> Coordinate system improvements (status: waiting on cairo)
> nsTextFrame rewrite (status: waiting on cairo for all platforms?)
>
> I feel like someone else mentioned something else but I'm forgetting
> it.... We should probably wiki this list.

Good idea.
I think though that there should be a separation of platform and
application changes ("Firefox on XULRunner" is basically an
application-only change, I guess, while the rest of the list are
platform changes).


Just for those who are interested, we also have application-specific
"big changes" on our list for SeaMonkey, which would be as follows:

consolidation of SeaMonkey-specific code in suite/
"source L10n" (support of cvs-based localization)
migration from xpfe to toolkit (with XULRunner as long-term target)

Status for all those is "started, but still in the early stages".

Robert Kaiser

Benjamin Smedberg

unread,
Apr 12, 2006, 11:59:54 AM4/12/06
to Mike Beltzner, Boris Zbarsky
Mike Beltzner wrote:

> I'm assuming we'd want people to be testing the platform, not just the
> Firefox product based on that platform. Also, I'm not sure that you
> want to tie the trunk release schedule into the Firefox 3 product
> release schedule ...

I'm not sure I understand the distinction in this case. People should
*always* be "testing the platform, not just the Firefox product based on the
platform". Even for Firefox 2 there is a decent chance that safe-looking
changes in the backend or frontend code could affect the web platform, not
just the user experience.

The trunk release schedule is intimately tied up with the Firefox 3 product
schedule of necessity: it's impossible to consider doing a "platform"
release without full and integrated testing of the primary platform consumer
(Firefox). All of the trunk work is targeted at a Firefox 3 release in Q1
2007. We need to start widespread testing of underlying changes now-ish in
order to have any chance of hitting that goal.

We may not want to call it a "Firefox 3 alpha" since the frontend is largely
the same as the Firefox 2 alphas. Basically what we need to release are
"bonecho alpha frontend with gecko 1.9a backend" bits, with at least a
little expectation of stability in both pieces. In my ideal world this would
happen at about the time of bonecho alpha-2 (mid-May). Call those bits what
you will to avoid confusion.

--BDS

Mike Connor

unread,
Apr 12, 2006, 12:24:58 PM4/12/06
to
Axel Hecht wrote:
> Mike Connor wrote:
>> Boris Zbarsky wrote:
>
> <...>
>
>> * Create an update channel for known-good nightlies (i.e.
>> mozilla-unstable)
>> * Push these builds for the web developer/webapps community via MDC
>> and other outlets
>> * Every second Thursday, close the tree and do smoketests on
>> Windows/Linux/Mac nightlies
>
> Every other week is a timeframe that is terribly hard to organize. I'd
> expect that someone checks into the closed tree each and every time, and
> closing the tree for one day every 14 sounds a bit intrusive to me.

What organization is needed? We close the tree for half a day to
smoketest stuff (which is basically three MozQA people for a few hours),
if things pass, we reopen the tree and dump those builds in the update
channel (preed or rhelmer can probably do this easily by now, especially
for only three builds).

The point is to spend less time frozen than we will if we're doing
bigger increments. We used to close the tree like this five days a
week, so what makes doing it once every two weeks so intrusive?

> I'd rather go for first whatever of the month.

Its easier, sure, but it means larger changesets and larger potential
regression windows to find regressions. It also would lead to more
bunching around freezes (needs testing, can't wait another month, etc),
which I'd like to avoid. The point is to catch things as soon as
possible and to make checkpoints frequent enough that there isn't a big
rush to hit any particular one.

Once we get into betas I think that's entirely possible that we could
bump up to once a week, since at that stage we should be able to
consistently ship stable builds.

> Whichever timeframe we end up with, we should coordinate that with the
> availability of builds to hunt down regression windows.

We'll still have these builds on the ftp somewhere for archiving/linking
from announcements (i.e. we would have a Gecko Team blog that we
announce these builds on, so people know what especially needs testing).

-- Mike

Mike Beltzner

unread,
Apr 12, 2006, 3:42:39 PM4/12/06
to Benjamin Smedberg, Boris Zbarsky, dev-pl...@lists.mozilla.org, dev-pl...@lists.mozilla.org
On 4/12/06, Benjamin Smedberg <benj...@smedbergs.us> wrote:
> The trunk release schedule is intimately tied up with the Firefox 3
> product schedule of necessity: it's impossible to consider doing a
> "platform" release without full and integrated testing of the primary
> platform consumer (Firefox). All of the trunk work is targeted at a
> Firefox 3 release in Q1 2007. We need to start widespread testing of
> underlying changes now-ish in order to have any chance of hitting that
> goal.

I guess I'm confused because I haven't really seen any firm plans
about the roadmap for Gecko 1.9, so this desire to "release" something
really looks more like a "we've been doing lots of stuff, and we want
people to poke at it" than a targeted or managed release.

While Firefox 3 is obviously a primary consumer of the platform, I
don't think we should tightly couple the release schedules. I think
the Gecko release should treat Firefox 3 as a consumer, and get
requirements in terms of scheduling and functionality just like it
would from any other consumer (such as XULRunner or Thunderbird) and
then triage and schedule appropriately. I'm not saying that it needs
to be confrontational or that the two things should work as if neither
exists, but we probably shouldn't just assume that "gecko 1.9 will be
done when Firefox 3 is released."

> the same as the Firefox 2 alphas. Basically what we need to release are
> "bonecho alpha frontend with gecko 1.9a backend" bits, with at least a
> little expectation of stability in both pieces. In my ideal world this

Exactly. I think what we're looking to release is a stable snapshot of
the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
site with all of the various applications (Fx, Tb, Sb?, XR?) that are
built off that codebase.

I want to avoid calling this a "3.0 Alpha" since those alphas should
be managed and scheduled by the groups that are focused on defining
what those v3 products will look like.

I know that I'm sort of splitting hairs here, but as we decouple the
product and platform development cycle, I think this sort of
differentiation is needed.

Boris Zbarsky

unread,
Apr 12, 2006, 3:48:56 PM4/12/06
to
Mike Beltzner wrote:
> I guess I'm confused because I haven't really seen any firm plans
> about the roadmap for Gecko 1.9

Other than the feature list, I assume?

> so this desire to "release" something
> really looks more like a "we've been doing lots of stuff, and we want
> people to poke at it" than a targeted or managed release.

That's correct. That's exactly what I want, at least. I'm not interested in
user-facing anything here; I just want feedback on which web sites and intranet
apps we've broken so we can fix them now, and not during the release crunch.

> Exactly. I think what we're looking to release is a stable snapshot of
> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
> built off that codebase.

Yep. And trumpet said snapshot a bit.

> I want to avoid calling this a "3.0 Alpha"

Agreed.

-Boris

Boris Zbarsky

unread,
Apr 12, 2006, 3:58:32 PM4/12/06
to
Mike Beltzner wrote:
> While Firefox 3 is obviously a primary consumer of the platform, I
> don't think we should tightly couple the release schedules. I think
> the Gecko release should treat Firefox 3 as a consumer, and get
> requirements in terms of scheduling and functionality just like it
> would from any other consumer (such as XULRunner or Thunderbird) and
> then triage and schedule appropriately.

I should note that that's filed twice already -- with Gecko 1.7 and Gecko 1.8.

The only way this can really work is if there is communication about
infrastructure changes needed by Firefox while Gecko is in an alpha cycle (or
before, e.g. if Firefox runs into issues with a given Gecko version, file bugs
so they will be fixed in the next one).

There's been a bit more of that this time around (at least in terms of Firefox
2; I have no idea what the state of Firefox 3 is), so maybe it'll all work out
this time.

Also, should we really be talking about the Gecko development cycle? Or the
XULRunner development cycle?

> but we probably shouldn't just assume that "gecko 1.9 will be
> done when Firefox 3 is released."

Sure, but at the same time we know Gecko 1.9 will not be done until at least a
beta of Firefox 3 is released -- we need the widespread testing that will provide.

-Boris

Chris Hofmann

unread,
Apr 12, 2006, 4:10:01 PM4/12/06
to Boris Zbarsky, dev-pl...@lists.mozilla.org
Boris Zbarsky wrote:
> Mike Beltzner wrote:
>> I guess I'm confused because I haven't really seen any firm plans
>> about the roadmap for Gecko 1.9
>
> Other than the feature list, I assume?
>
>> so this desire to "release" something
>> really looks more like a "we've been doing lots of stuff, and we want
>> people to poke at it" than a targeted or managed release.
>
> That's correct. That's exactly what I want, at least. I'm not
> interested in user-facing anything here; I just want feedback on which
> web sites and intranet apps we've broken so we can fix them now, and
> not during the release crunch.
The problem with this is that to get a significant level folks to use
the build long enough to provide good, in-depth, usage and feedback the
user facing parts need to be in good enough shape that they will use the
app for their daily work and extended periods of time. So finding and
fixing up any critical user facing problems is key to getting some
testing and feedback on websites and intranet apps.

>
>> Exactly. I think what we're looking to release is a stable snapshot of
>> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
>> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
>> built off that codebase.
>
> Yep. And trumpet said snapshot a bit.

Its going to be tough to get any widespread testing of trunk snapshot
builds named "minefield"... I think that code name, or
characterization, or branding for trunk builds is the wrong direction to
be heading in. We should be continuing to encourage and create a large
development and testing community of 10,000 to 20,000 or more to help
out in keeping the trunk as stable as possible at all times. We should
be and keeping destabilizing changes away from the trunk until they are
baked and ready to land. minefield sends the wrong message if these are
still our goals. This becomes harder the more branches we are working
on in parallel, but I still think it is a goal.

>
>> I want to avoid calling this a "3.0 Alpha"
>
> Agreed.
>
> -Boris

Benjamin Smedberg

unread,
Apr 12, 2006, 4:24:54 PM4/12/06
to Mike Beltzner, Boris Zbarsky
Mike Beltzner wrote:

> I guess I'm confused because I haven't really seen any firm plans

> about the roadmap for Gecko 1.9, so this desire to "release" something


> really looks more like a "we've been doing lots of stuff, and we want
> people to poke at it" than a targeted or managed release.

Perhaps I (we) don't understand what you mean by a targeted or managed
release. We had a set of goals to accomplish for "the platform", including
the reflow branch, cairo graphics, xulrunner, whatnot... we need to have
releases at various checkpoints to collect feedback/regression/performance data.

> While Firefox 3 is obviously a primary consumer of the platform, I
> don't think we should tightly couple the release schedules. I think

On the contrary, I think we absolutely *must* tightly couple the release
schedules: it is impossible to release "the platform" without thorough
testing coverage, and the only sane way to get thorough test coverage is
through Firefox releases.

> the Gecko release should treat Firefox 3 as a consumer, and get
> requirements in terms of scheduling and functionality just like it
> would from any other consumer (such as XULRunner or Thunderbird) and

If we're splitting hairs, these are very different examples. XULRunner is at
its least a build artifact of "the platform", and at most a full
productization of the platform. Thunderbird is a client app.

> exists, but we probably shouldn't just assume that "gecko 1.9 will be


> done when Firefox 3 is released."

How would you do otherwise. There is absolutely no point in releasing gecko
1.9 before Firefox 3 is finished (because the QA and testing of the platform
happens in Firefox release cycles); and it's obviously not possible to say
that gecko 1.9 could be done after FF3.

> I know that I'm sort of splitting hairs here, but as we decouple the
> product and platform development cycle, I think this sort of
> differentiation is needed.

I do not think that we have "decoupled" these cycles at all. We have put two
product cycles into a platform cycle, and made some guarantees about
platform stability between those two releases (for the benefit of the web
and the low-level extension ecosystem, primarily). That's not the same thing
at all as a decoupled schedule.

--BDS

L. David Baron

unread,
Apr 12, 2006, 4:34:55 PM4/12/06
to dev-pl...@lists.mozilla.org
On Wednesday 2006-04-12 15:42 -0400, Mike Beltzner wrote:
> I guess I'm confused because I haven't really seen any firm plans
> about the roadmap for Gecko 1.9, so this desire to "release" something
> really looks more like a "we've been doing lots of stuff, and we want
> people to poke at it" than a targeted or managed release.

I don't see why you think releases have to be built that way.

There are too many people working on different areas of Gecko to
coordinate in that way. The different areas (in which developers can
swtich from one piece of code to another) often do have more detailed
plans -- in terms of what is higher and lower priority. Then once
there's a targeted release date they know what's unsafe to do in time to
be stable for the release. But there's no reason that the people
working on layout, DOM, or networking have to agree in advance which of
their features will make it in -- then incorrect time estimates could
easily lead to one of those groups being ready for the release 6 months
before another. This is exactly the problem that's caused huge amounts
of tension around recent Firefox releases.

But that doesn't mean these changes don't need testing in alpha form.

> > the same as the Firefox 2 alphas. Basically what we need to release are
> > "bonecho alpha frontend with gecko 1.9a backend" bits, with at least a
> > little expectation of stability in both pieces. In my ideal world this
>

> Exactly. I think what we're looking to release is a stable snapshot of
> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
> built off that codebase.

I don't think this makes sense. The vast majority of the changes that
need widespread testing are changes that affect how we display Web
pages. Thus the key here is releasing a Web browser. Releasing
everything else would just make shipping an alpha harder, when it can
really be something that's really easy to do, relative to most of the
other things the build team does.

-David

--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation

L. David Baron

unread,
Apr 12, 2006, 4:52:59 PM4/12/06
to dev-pl...@lists.mozilla.org
On Wednesday 2006-04-12 13:10 -0700, Chris Hofmann wrote:
> Its going to be tough to get any widespread testing of trunk snapshot
> builds named "minefield"... I think that code name, or
> characterization, or branding for trunk builds is the wrong direction to
> be heading in. We should be continuing to encourage and create a large
> development and testing community of 10,000 to 20,000 or more to help
> out in keeping the trunk as stable as possible at all times. We should
> be and keeping destabilizing changes away from the trunk until they are
> baked and ready to land. minefield sends the wrong message if these are
> still our goals. This becomes harder the more branches we are working
> on in parallel, but I still think it is a goal.

Agreed.

And what's pissed me off about our release process ever since Firefox
became the flagship app is that the Firefox leads have insisted on
controlling the Firefox release process as if it weren't also the
primary testing and release vehicle for Gecko.

This is why, following Firefox 1.0, I sat down with Ben and many others
to develop a plan that would allow Firefox to really become the flagship
Gecko app:
http://groups.google.com/group/netscape.public.mozilla.seamonkey/msg/0883b9b35d3400af
Part of this Firefox 1.1 (later 1.5) plan involved shipping a
Firefox-based Gecko alpha in early January of 2005. The agreement by
the Firefox leads to that 1.1 plan was the only reason I accepted
dropping the suite as the flagship Gecko app.

That plan was nowhere close to being met, and it now seems like the
current Firefox leads aren't even willing to accept its rationale --
that Gecko needs to ship reasonably frequent Web browser alphas to tens
or hundreds of thousands of users so that regressions in handling of Web
pages are found. This requires more users than most other types of
testing-by-alpha because most Web pages are used by only a tiny portion
of Web users.

If Firefox leads aren't comfortable with what being the flagship Gecko
app means, then I think we need to restore the Mozilla Suite to that
role -- not because I like the suite, but because we need a Web browser
that we can release to get Gecko testing.

Robert Kaiser

unread,
Apr 12, 2006, 5:31:35 PM4/12/06
to
L. David Baron schrieb:

> I don't think this makes sense. The vast majority of the changes that
> need widespread testing are changes that affect how we display Web
> pages. Thus the key here is releasing a Web browser. Releasing
> everything else would just make shipping an alpha harder, when it can
> really be something that's really easy to do, relative to most of the
> other things the build team does.

This should be Gecko test releases, right?

So why not just release a Firefox snapshot officially branded as "Gecko
Browser Preview 2006-06-24" or something like that?

The "Gecko Browser" name has been used previously for nightlies already,
and it would make clear what it's about, additionally give the "Gecko"
brand some publicity among testers and web developers.

I think though that actually providing XULRunner binaries along with
those alpha snapshots might be a good idea, so that other (possibly
external) platform users have their target for testing with newer
versions. And as Firefox (or "Gecko Browser" for that matter) should
only be an additional layer on top of a "vanilla" XULRunner, it should
probably be easy to do both packages in one run.

Robert Kaiser

Mike Beltzner

unread,
Apr 12, 2006, 6:53:32 PM4/12/06
to Chris Hofmann, Boris Zbarsky, dev-pl...@lists.mozilla.org
On 4/12/06, Chris Hofmann <chof...@mozilla.org> wrote:
> >> so this desire to "release" something
> >> really looks more like a "we've been doing lots of stuff, and we want
> >> people to poke at it" than a targeted or managed release.
> >
> > That's correct. That's exactly what I want, at least. I'm not
> > interested in user-facing anything here; I just want feedback on which
> > web sites and intranet apps we've broken so we can fix them now, and
> > not during the release crunch.
>
> The problem with this is that to get a significant level folks to use
> the build long enough to provide good, in-depth, usage and feedback the
> user facing parts need to be in good enough shape that they will use the
> app for their daily work and extended periods of time. So finding and
> fixing up any critical user facing problems is key to getting some
> testing and feedback on websites and intranet apps.

Well, we're still landing all the new front end features on both the
1.8-branch and the trunk, right? So if we target this trunk release to
be coincident with a 1.8-branch release, then we shouldn't need to
worry about the user-facing parts not being good enough.

I think the issue we need to worry about is splitting our testing
community: should they be testing the browser using trunk or branch? I
can see arguments for both, really. For instance, in the short term,
the success of Firefox 2 depends on getting a lot of eyes testing
those user-facing features without having them distracted by the
platform related regressions or bustages. In the long term, as both
you and dbaron mention, we need eyes on the platform related stuff.

> >> Exactly. I think what we're looking to release is a stable snapshot of
> >> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
> >> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
> >> built off that codebase.
> >
> > Yep. And trumpet said snapshot a bit.

> Its going to be tough to get any widespread testing of trunk snapshot
> builds named "minefield"... I think that code name, or

I call "straw man". Nobody ever suggested that a published "release"
should be called Minefield. That name, as mentioned over and over
again in bug 308973, is intended to be used as the default branding
for apps built right off the trunk specifically to warn people that
there's no guarantee of stability. If we were to take a snapshot that
was known to be stable, we'd presumably give it a different name.

> characterization, or branding for trunk builds is the wrong direction to
> be heading in. We should be continuing to encourage and create a large
> development and testing community of 10,000 to 20,000 or more to help
> out in keeping the trunk as stable as possible at all times. We should

Out of curiousity, how many people are running trunk nightlies? What's
the delta we're looking to attract here?

Mike Connor

unread,
Apr 12, 2006, 8:28:27 PM4/12/06
to dev-pl...@lists.mozilla.org
Chris Hofmann wrote:
> Boris Zbarsky wrote:
>> Mike Beltzner wrote:
>>> I guess I'm confused because I haven't really seen any firm plans
>>> about the roadmap for Gecko 1.9
>>
>> Other than the feature list, I assume?
>>
>>> so this desire to "release" something
>>> really looks more like a "we've been doing lots of stuff, and we want
>>> people to poke at it" than a targeted or managed release.
>>
>> That's correct. That's exactly what I want, at least. I'm not
>> interested in user-facing anything here; I just want feedback on
>> which web sites and intranet apps we've broken so we can fix them
>> now, and not during the release crunch.
> The problem with this is that to get a significant level folks to use
> the build long enough to provide good, in-depth, usage and feedback
> the user facing parts need to be in good enough shape that they will
> use the app for their daily work and extended periods of time. So
> finding and fixing up any critical user facing problems is key to
> getting some testing and feedback on websites and intranet apps.
I think we need to resurrect dogfood and apply/enforce it aggressively,
but that doesn't change the fact that the focus of any trunk
releases/testing is the backend, and as long as the core functionality
is there, we should be ok.

>>> Exactly. I think what we're looking to release is a stable snapshot of
>>> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
>>> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
>>> built off that codebase.
>>
>> Yep. And trumpet said snapshot a bit.
> Its going to be tough to get any widespread testing of trunk snapshot
> builds named "minefield"... I think that code name, or
> characterization, or branding for trunk builds is the wrong direction
> to be heading in. We should be continuing to encourage and create a
> large development and testing community of 10,000 to 20,000 or more
> to help out in keeping the trunk as stable as possible at all times.
> We should be and keeping destabilizing changes away from the trunk
> until they are baked and ready to land. minefield sends the wrong
> message if these are still our goals. This becomes harder the more
> branches we are working on in parallel, but I still think it is a goal.
People who are going to be useful testers against ongoing Gecko
development are not going to be scared off by the fact that its called
Minefield. Especially right now, nightlies, even more stable ones, are
going to be somewhat unpredictable, and may have grandma killing bugs we
haven't found out about. We've absolutely done that in the past, and
will continue to do that in the future, so full disclosure even in
naming shouldn't be a problem. If users are willing to be real dogfood
users, then the name shouldn't be a problem. That said, doing more
parallel work would be nice, but we've optimized away from that in the
last couple of years, maybe we need to rethink that.

Based on some handwavy stats from AUS, we currently have around 6000
people using nightlies every day. There were 12k unique users of
nightlies in the first half of March, so that really seems like we're
already mostly there. Do we need more? More is always better, but only
if those additional users are going to file good bugs and help out in
that kind of way. Quality, not quantity, of testing is the benchmark we
need to focus on, IMO.

-- Mike

Boris Zbarsky

unread,
Apr 13, 2006, 12:32:48 AM4/13/06
to
Mike Beltzner wrote:
> I think the issue we need to worry about is splitting our testing
> community: should they be testing the browser using trunk or branch?

Some of both, unfortunately. I thought part of the point of keeping the UI in
sync was that trunk testing happening right now would still benefit Firefox 2,
so we could try to move testing resources to trunk as needed.

> In the long term, as both
> you and dbaron mention, we need eyes on the platform related stuff.

That long term is now, imo. Again, it's been 8 months since we branched... How
much longer term could we really get? ;)

Back to scheduling, if we _can_ do the trunk release at about the same time as a
branch release then you're probably right that the UI should be fairly
non-busted. So what does the branch release schedule look like?

-Boris

Jonas Sicking

unread,
Apr 13, 2006, 12:46:35 AM4/13/06
to
(reposting this to the right newsgroup)

There are a few things that I think are important.

First of all I'm worried about confusion if we release a FF 3 alpha
before FF 2 is out the door. However, this problem would be lessened a
lot, or even go away, if we name the release something other then
"Firefox 3 alpha".

Second, I think we need to make sure we get the right people to download
and test this thing. We have had a problem in the past with people not
testing heavily until it's too late to actually fix bad regressions.
Unfortunately I don't really have a good answer to this one, other than
possibly saying "don't spend time on too many alphas that don't get
heavy testing anyway". Really, do we get a lot of people testing alphas
that aren't already testing nightlies?

Lastly, I think deciding on an aimed release date is the first thing we
should do since without that anything we do is likely too early or too
late. We probably don't need to hammer out an exact date, but within a
month or two seems reasonable.

/ Jonas

Mike Beltzner

unread,
Apr 13, 2006, 12:55:48 AM4/13/06
to Benjamin Smedberg, Boris Zbarsky, dev-pl...@lists.mozilla.org, dev-pl...@lists.mozilla.org
On 4/12/06, Benjamin Smedberg <benj...@smedbergs.us> wrote:
> Mike Beltzner wrote:
>
> > I guess I'm confused because I haven't really seen any firm plans
> > about the roadmap for Gecko 1.9, so this desire to "release" something
> > really looks more like a "we've been doing lots of stuff, and we want
> > people to poke at it" than a targeted or managed release.
>
> Perhaps I (we) don't understand what you mean by a targeted or managed
> release. We had a set of goals to accomplish for "the platform",
> including the reflow branch, cairo graphics, xulrunner, whatnot... we
> need to have releases at various checkpoints to collect
> feedback/regression/performance data.

I mean that I don't know where the set of things that are going into
trunk is being catalogued, nor do I know where I can get a sense of
what the targets are for alphas, betas, and release candidates for the
trunk. Nor, really, do I know how those releases will be expressed,
but that seems to be precisely what we're talking about atm :)

So I'm confused about the goal: do we want to publish an alpha
release, where we set firm goals about what will or won't be in that
release, and scope priorities in terms of moving the trunk from one
milestone to the next, or do we want to simply ensure that there's a
stable state for the trunk such that people testing that code can grab
a version of their app that they can expect to not cause dataloss,
etc?

>From what I'm hearing so far, the goal is actually the latter, and I
think it's something that should definitely be done. So then it comes
down to, well, what's the best way to do that? I think we all agree
that calling it "Firefox 3 Alpha" isn't the right thing to do, since
that's gonna get misinterpreted by the general public. That was why I
suggested that we just publish those nightly builds and put them in a
directory called /latest-trunk-stable or something, and then blog and
announce that we have a set of trunk builds that are stable enough for
daily use, and would appreciate early adopters using those for their
daily surfing.

Heck, I'd even rather that people use those builds than Bon Echo
Alphas, since they'll both have the same front-end features, and
really the Bon Echo project would benefit from any bug reports that
were recieved.

> On the contrary, I think we absolutely *must* tightly couple the release
> schedules: it is impossible to release "the platform" without thorough
> testing coverage, and the only sane way to get thorough test coverage is
> through Firefox releases.

Hm, maybe you're right, and I'm being too aggressive here in my
conceptualization. What I'm getting at is that I feel like we need to
shift our way of thinking about things so that people developing the
trunk aren't forced to do so *only* in service of Firefox. So the
platform is considered to be its own product, and apps built off of it
like Firefox will pick stable-ish points from which to cut branches
that will become the base of their releases. This nets out to mostly a
semantic difference, I guess.

Mike Beltzner

unread,
Apr 13, 2006, 1:01:23 AM4/13/06
to dev-pl...@lists.mozilla.org, dev-pl...@lists.mozilla.org
On 4/12/06, L. David Baron <dba...@dbaron.org> wrote:
> On Wednesday 2006-04-12 13:10 -0700, Chris Hofmann wrote:
> > Its going to be tough to get any widespread testing of trunk snapshot
> > builds named "minefield"... I think that code name, or
> > characterization, or branding for trunk builds is the wrong direction to

> > be heading in. We should be continuing to encourage and create a large
> > development and testing community of 10,000 to 20,000 or more to help
> > out in keeping the trunk as stable as possible at all times. We should
> > be and keeping destabilizing changes away from the trunk until they are
> > baked and ready to land. minefield sends the wrong message if these are
> > still our goals. This becomes harder the more branches we are working
> > on in parallel, but I still think it is a goal.
>
> Agreed.
>
> And what's pissed me off about our release process ever since Firefox
> became the flagship app is that the Firefox leads have insisted on
> controlling the Firefox release process as if it weren't also the
> primary testing and release vehicle for Gecko.
>
> This is why, following Firefox 1.0, I sat down with Ben and many others
> to develop a plan that would allow Firefox to really become the flagship
> Gecko app:
> http://groups.google.com/group/netscape.public.mozilla.seamonkey/msg/0883b9b35d3400af
> Part of this Firefox 1.1 (later 1.5) plan involved shipping a
> Firefox-based Gecko alpha in early January of 2005. The agreement by
> the Firefox leads to that 1.1 plan was the only reason I accepted
> dropping the suite as the flagship Gecko app.
>
> That plan was nowhere close to being met, and it now seems like the
> current Firefox leads aren't even willing to accept its rationale --
> that Gecko needs to ship reasonably frequent Web browser alphas to tens
> or hundreds of thousands of users so that regressions in handling of Web
> pages are found. This requires more users than most other types of
> testing-by-alpha because most Web pages are used by only a tiny portion
> of Web users.

So we get tens of thousands of people testing trunk builds. And then
we get hundreds of thousands of more casual users testing product
alphas and betas. And when the product releases start building off of
trunk, the number of testers on trunk jumps up nicely to coincide with
the point in time where trunk code is ready to expand to a wider
testing audience.

Win-win, isn't it?

> If Firefox leads aren't comfortable with what being the flagship Gecko
> app means, then I think we need to restore the Mozilla Suite to that
> role -- not because I like the suite, but because we need a Web browser
> that we can release to get Gecko testing.

What do you mean when you say "release"? What's involved there in
terms of engineering, publicity and socialization?

Mike Beltzner

unread,
Apr 13, 2006, 1:04:35 AM4/13/06
to Boris Zbarsky, dev-pl...@lists.mozilla.org, dev-pl...@lists.mozilla.org
On 4/13/06, Boris Zbarsky <bzba...@mit.edu> wrote:
> Mike Beltzner wrote:
> > I think the issue we need to worry about is splitting our testing
> > community: should they be testing the browser using trunk or branch?
>
> Some of both, unfortunately. I thought part of the point of keeping the
> UI in sync was that trunk testing happening right now would still benefit
> Firefox 2, so we could try to move testing resources to trunk as needed.

I think it was mostly to reduce the pain of merging back to trunk from
a branch, as was experienced with aviary->gecko 1.8. That was the
rumour I heard or read off a bathroom wall or something, anyway ;)

> > In the long term, as both
> > you and dbaron mention, we need eyes on the platform related stuff.
>
> That long term is now, imo. Again, it's been 8 months since we
> branched... How much longer term could we really get? ;)

You don't actually want an answer to that question, do you?

> Back to scheduling, if we _can_ do the trunk release at about the same
> time as a branch release then you're probably right that the UI should be
> fairly non-busted. So what does the branch release schedule look like?

We're targetting Bon Echo Alpha 2 at May 9th at the moment, with code
freeze on May 5th. There's a rough schedule for B1, B2 and the RCs at
http://wiki.mozilla.org/Firefox2/Schedule

cheers,
mike

Boris Zbarsky

unread,
Apr 13, 2006, 1:42:37 AM4/13/06
to
Mike Beltzner wrote:
> I mean that I don't know where the set of things that are going into
> trunk is being catalogued

http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan has some info, but I
agree that this list is not being maintained. I'll try to set up a wiki page
with the list I have compiled so far and whatever "owner", status, and date info
I can come up with... That's just in terms of the code.

> nor do I know where I can get a sense of what the targets are for alphas, betas, and release candidates for the
> trunk. Nor, really, do I know how those releases will be expressed,
> but that seems to be precisely what we're talking about atm :)

Right.

> So I'm confused about the goal: do we want to publish an alpha
> release, where we set firm goals about what will or won't be in that
> release, and scope priorities in terms of moving the trunk from one
> milestone to the next, or do we want to simply ensure that there's a
> stable state for the trunk

I don't think we can do the latter without doing the former for trunk work.
Otherwise we'll just have big landings happening just about as we stabilize from
the previous landing. So yes, I think we need to ensure a stable state for the
trunk and to that end we need firm goals about what will be in that stable state
(and what won't be, probably). Getting this defined was one of the things I
wanted to come out of this thread.

> I think we all agree
> that calling it "Firefox 3 Alpha" isn't the right thing to do, since
> that's gonna get misinterpreted by the general public.

Well, it's not clear that everyone agreed, but I'm personally ok with calling it
something else (I stand by my "Firefox 3 Developer Preview" suggestion). Unless
your problem is with the "3" in there?

-Boris

L. David Baron

unread,
Apr 13, 2006, 1:50:34 AM4/13/06
to dev-pl...@lists.mozilla.org, dev-pl...@lists.mozilla.org
On Thursday 2006-04-13 01:01 -0400, Mike Beltzner wrote:
> > That plan was nowhere close to being met, and it now seems like the
> > current Firefox leads aren't even willing to accept its rationale --
> > that Gecko needs to ship reasonably frequent Web browser alphas to tens
> > or hundreds of thousands of users so that regressions in handling of Web
> > pages are found. This requires more users than most other types of
> > testing-by-alpha because most Web pages are used by only a tiny portion
> > of Web users.
>
> So we get tens of thousands of people testing trunk builds. And then

Whatever the number we have testing trunk builds, it isn't enough. (And
it sounds like it might be ten thousand, but not tens of thousands.) We
got too many very-old regressions filed once Firefox 1.5 started
shipping alphas and betas, and it's probably going to happen again (and
perhaps even worse) for 3.0, at the rate we're going.

Regression bug reports are much more useful when the code is still fresh
in its authors' mind, and when there's enough time to fix them before
the release.

> we get hundreds of thousands of more casual users testing product
> alphas and betas.

Not at any reasonable interval.

> And when the product releases start building off of
> trunk, the number of testers on trunk jumps up nicely to coincide with
> the point in time where trunk code is ready to expand to a wider
> testing audience.

We need it to hit a wider testing audience more often than we do now.

And I don't see why you think the trunk Gecko code becomes more ready to
expand to a wider testing audience when Firefox has met its
product-planned goals.

> Win-win, isn't it?

No, and I think you already knew I thought not.

Mike Beltzner

unread,
Apr 13, 2006, 2:51:42 AM4/13/06
to dev-pl...@lists.mozilla.org, dev-pl...@lists.mozilla.org
On 4/13/06, L. David Baron <dba...@dbaron.org> wrote:
> On Thursday 2006-04-13 01:01 -0400, Mike Beltzner wrote:
> > > That plan was nowhere close to being met, and it now seems like the
> > > current Firefox leads aren't even willing to accept its rationale --
> > > that Gecko needs to ship reasonably frequent Web browser alphas to tens
> > > or hundreds of thousands of users so that regressions in handling of Web
> > > pages are found. This requires more users than most other types of
> > > testing-by-alpha because most Web pages are used by only a tiny portion
> > > of Web users.
> >
> > So we get tens of thousands of people testing trunk builds. And then
>
> Whatever the number we have testing trunk builds, it isn't enough. (And
> it sounds like it might be ten thousand, but not tens of thousands.) We
> got too many very-old regressions filed once Firefox 1.5 started
> shipping alphas and betas, and it's probably going to happen again (and
> perhaps even worse) for 3.0, at the rate we're going.
[...]

> Regression bug reports are much more useful when the code is still fresh
> in its authors' mind, and when there's enough time to fix them before
> the release.

You're coming up with a lot of great points for why we need more
testing on trunk, and I'm sold on the idea, but I don't see any
counter-proposals to the solutions that I'm putting forward. Are you
proposing that we do frequent releases of Firefox off the trunk? What
would constitute such a release? Why do you expect that doing so would
get more people using that version for their web browsing?

The way I see it, there are a couple of options:

1. Firefox 2 releases as planned. Simultaneously, stabilize trunk such
that a set of solid builds can be made at some regular interval (let's
say monthly?) and then call those builds "latest-stable-trunk" or
something and socialize the need for testing and how these builds are
good enough for day to day use.

2. Firefox 2 releases as planned. Quickly build out a set of milestone
dates for Firefox 3 (with several alphas) and start releasing those as
well, perhaps initially synchronized to the Firefox 2 release
schedule. Or maybe it would be better to stagger the releases such
that our testers could use one for a month, then another for a month,
etc.

3. Make Firefox 3 releases the "flagship" alphas which we ask people
to use, since any front-end bugs will be discovered from here, too.
When the front-end stuff reaches beta level, then continue publishing
alphas from trunk, but also release Firefox 2 betas based on the 1.8
branch.

> > we get hundreds of thousands of more casual users testing product
> > alphas and betas.
>
> Not at any reasonable interval.
>
> > And when the product releases start building off of
> > trunk, the number of testers on trunk jumps up nicely to coincide with
> > the point in time where trunk code is ready to expand to a wider
> > testing audience.
>
> We need it to hit a wider testing audience more often than we do now.

Just "releasing" something doesn't guarantee a wider test audience.
Were I not in the know, I'd have no idea if I should be using Firefox
2 or Firefox 3. Also, I want people paying attention and submitting
bugs on the front end changes as well; you seem to be implying that
these code changes are less risky/worth testing than trunk changes.

> And I don't see why you think the trunk Gecko code becomes more ready to
> expand to a wider testing audience when Firefox has met its
> product-planned goals.

Didn't mean to imply that, sorry, my bad. What I meant to imply was
that if we assume that the number of testers is a finite resource, and
if we have to prioritize where their attention should go, then I would
suggest that we try to focus that resource more on our n+1 product
than on our n+2 initially, and then shift it as we get close to
releasing n+1.

> > Win-win, isn't it?
>
> No, and I think you already knew I thought not.

Believe it or not, I was actually hoping that we might have been
moving towards some sort of constructive solution. Apparently I'm
still new enough to have that kind of optimism.

L. David Baron

unread,
Apr 13, 2006, 3:15:18 AM4/13/06
to dev-pl...@lists.mozilla.org, dev-pl...@lists.mozilla.org
On Thursday 2006-04-13 02:51 -0400, Mike Beltzner wrote:
> The way I see it, there are a couple of options:
>
> 1. Firefox 2 releases as planned. Simultaneously, stabilize trunk such
> that a set of solid builds can be made at some regular interval (let's
> say monthly?) and then call those builds "latest-stable-trunk" or
> something and socialize the need for testing and how these builds are
> good enough for day to day use.
>
> 2. Firefox 2 releases as planned. Quickly build out a set of milestone
> dates for Firefox 3 (with several alphas) and start releasing those as
> well, perhaps initially synchronized to the Firefox 2 release
> schedule. Or maybe it would be better to stagger the releases such
> that our testers could use one for a month, then another for a month,
> etc.
>
> 3. Make Firefox 3 releases the "flagship" alphas which we ask people
> to use, since any front-end bugs will be discovered from here, too.
> When the front-end stuff reaches beta level, then continue publishing
> alphas from trunk, but also release Firefox 2 betas based on the 1.8
> branch.

I'm happy with any of these, at least assuming (1) would be done in a
prominent enough way that it gets users. I expect others would be
unhappy with (3), and I wasn't pushing for it.

> > > Win-win, isn't it?
> >
> > No, and I think you already knew I thought not.
>
> Believe it or not, I was actually hoping that we might have been
> moving towards some sort of constructive solution. Apparently I'm
> still new enough to have that kind of optimism.

Then I must have misread your message: when you wrote "we get", I
thought you were describing the present situation, but I think you
actually were describing the result of the proposed changes (for which I
would have used "we would get").

Robert Kaiser

unread,
Apr 13, 2006, 7:43:39 AM4/13/06
to
Mike Beltzner schrieb:

> What I'm getting at is that I feel like we need to
> shift our way of thinking about things so that people developing the
> trunk aren't forced to do so *only* in service of Firefox. So the
> platform is considered to be its own product, and apps built off of it
> like Firefox will pick stable-ish points from which to cut branches
> that will become the base of their releases. This nets out to mostly a
> semantic difference, I guess.

In a world where apps are all created on top of identical XULRunner
builds (and I think we agree that this should be the future for all of
us), the model we are working towards works fine, basically as you
described:

The platform (under the name of XULRunner) gets branched for a stable
release at some point, and apps do their stabilizing on the same branch
possibly (touching only their app-specific directory, i.e. browser/,
mail/, suite/, composer/, etc.) and are able to release off a point
that's declared "stable" by XULRunner developers.
Of course, they can always release at a later point using the same
stable XULRunner state/release, e.g. by doing a minibranch (client.mk +
their app-specific dir) off the release tag/minibranch/branch.

Releasing platform/XULRunner alphas (directly off trunk, probably
without the effort of branching) in between should be very much
scheduled (monthly, date-versioned?), so that any apps that want to
release own pre-releases from such a stable-ish point can either try to
stabilize at the same point or do their own minibranch based on that
platform alpha tree. For sure, the projects should know when they can
schedule for themselves to get to such a point (give or take a few days,
of course).

Still, the platform/XULRunner alphas need some "tesing instrument" which
is a showcase for the platform, and esp. for Gecko, so releasing a
"Gecko Browser" (i.e. Firefox) xulapp along with it would be a good idea.

At least, that sounds good for the glorious future where XULRunner is a
well-defined common base for all our apps. In the mean time, where we
still have no single app that's fully XULRunner-based and ready for a
preview-release, we can work towards such a sheme though, and use all
elements of it that do already fit.
Jugding from how we are/were dealing with releases off the 1.8.0 branch
(esp. Firefox/Thunderbird and SeaMonkey), we are not quite as far from
that model as one might think - though it needs much more coodination
with affected groups as it probably will in the fully XULRunner-based
world (though coordination and communication between projects and
platform is always a good idea).

Robert Kaiser

Jonas Sicking

unread,
Apr 13, 2006, 6:06:08 PM4/13/06
to
A thought just occurred to me (you just know this is gonna be bad, don't
you)

The primary reason we're releasing alphas and betas is that we want
people to test stuff with it. Like we want web-developers to test that
their site works, and we want extension-developers to test that their
extensions still work.

However, a lot of people are vary of installing an alpha version that
might wreck their bookmarks, eat their preferences and stomp on their
cookies.

So I wonder if it might make sense to create a distro that is more
sandboxed and is less likely to screw up their day-to-day firefox install.

In fact, there already is such a distro: Portable firefox.

If we could put portable versions of our releases right visible on the
alpha page and in the alpha announcements, people might be more willing
to give it a go.

We could even make portable firefox to optionally import the config
files of an existing install.

What do people think? Is it worth the effort? Maybe this is more
important to the later alphas?

/ Jonas

Jonas Sicking

unread,
Apr 13, 2006, 6:15:54 PM4/13/06
to
Boris Zbarsky wrote:
> Mike Beltzner wrote:
>> I think the issue we need to worry about is splitting our testing
>> community: should they be testing the browser using trunk or branch?
>
> Some of both, unfortunately. I thought part of the point of keeping the
> UI in sync was that trunk testing happening right now would still
> benefit Firefox 2, so we could try to move testing resources to trunk as
> needed.

I'm not sure that there is a huge advantage in shipping an alpha now, as
opposed to shipping one a bit after FF2 is out the door. Regressions are
generally not too hard to fix, it is finding them that is the problem.
So it might not be too bad to live with a regression a bit longer on the
trunk and make sure that we get a lot of testing at some point well
before we're approaching any sort of freeze.

So I think a well trumpeted, well tested alpha a bit down the road is
better then a half-trumpeted and half-tested now, and another
half-trumpeted and half-tested a bit later. In other words, I think it's
better to get more people testing, then to get the same people to test
multiple times.

I think (someone correct me if i'm overly optimistic) that we're keeping
good enough quality through the nightly releases that we don't have a
lot of test-blocking level bugs.

/ Jonas

fantasai

unread,
Apr 13, 2006, 6:53:30 PM4/13/06
to
schiller wrote:
> Slightly selfish, er, tangential question here: Are there any
> requirements on what delta SVG functionality will make it into Fx3? I
> know there was a big piece outstanding for Declarative Animation/SMIL
> (done by this guy:
> http://brian.sol1.net/svg/2006/01/09/smil-animation-in-mozilla-report/)
> but I'm not sure if this will make it for Fx3.
>
> Is the idea something like "whatever the SVG guys can get done and
> stable in time" or are there specific criteria, like "all of SVG 1.1"
> :) ?

I can't imagine a day when "all of SVG 1.1" will be on the requirements list.

~fantasai

Boris Zbarsky

unread,
Apr 14, 2006, 5:48:32 PM4/14/06
to
Jonas Sicking wrote:
> I'm not sure that there is a huge advantage in shipping an alpha now, as
> opposed to shipping one a bit after FF2 is out the door. Regressions are
> generally not too hard to fix, it is finding them that is the problem.

This is not my experience with changes to architecture. Often, fixing
regressions requires further architecture changes...

> So it might not be too bad to live with a regression a bit longer on the
> trunk and make sure that we get a lot of testing at some point well
> before we're approaching any sort of freeze.

The problem is that if at that point we have a number of regressions that make
the builds not testable by the general public then we have to do multiple alpha
cycles as the regressions are discovered. If we start having alphas later,
we'll have fewer alpha cycles, which will, imo, mean fewer regressions found.

> So I think a well trumpeted, well tested alpha a bit down the road is
> better then a half-trumpeted and half-tested now, and another
> half-trumpeted and half-tested a bit later.

I'm not sure I buy that, but in any case it's worse than a half-trumpeted one
now and a well-trumpeted one later. I'm not proposing we skip on later alphas
just because we do one sooner.

> I think (someone correct me if i'm overly optimistic) that we're keeping
> good enough quality through the nightly releases that we don't have a
> lot of test-blocking level bugs.

I think you're being overly optimistic. As a simple example, I'm currently
using a February nightly for most of my browsing; there have been regressions
almost constantly in various functionality areas since then, and the switch to
Cairo makes our nightlies unusably slow on my computer (3-4 seconds to repaint
the window after I do any window manager operation; 1-2 seconds to repaint when
the window loses or gains focus).

So the current trunk quality is certainly blocking testing by me, as far as that
goes.

-Boris

fantasai

unread,
Apr 14, 2006, 8:46:55 PM4/14/06
to
Ok, so here's what I'm understanding so far. Correct me if I'm wrong.

Issues:

- *Gecko trunk needs more testing, especially by web-developer types*
-> Need a browser front end, other apps not as important for this
(Boris writes: I just want feedback on which web sites and


intranet apps we've broken so we can fix them now, and not

during the release crunch.)

- *Want to catch regressions in Gecko earlier in the release cycle*

- *There are some major Gecko changes just in / going in* within the
next month or two that need widespread QA exposure.
-> bz is compiling a list of these

- Trunk firefox code is synced with FF2 branch
-> Using its front end will be a useful QA windfall for FF team,
even though that's not the focus here

- Triage could use more blocking nomination flags for Gecko
-> Should have flags for at least one alpha and one beta release
(Axel writes: It's more important to separate a1 and b1 than a1
and a2 at the current stage, so that one can decide "well, I'd
ship an alpha with this, but not a beta".)

Release Planning Ideas:

- Release a rebranded Firefox as the Gecko testing vehicle
-> Nightlies are branded as "Minefield".
-> Proposed names for Gecko releases include:
- Gecko Browser Preview 2006-06-24 (or something like that)
- restarting old Milestone system
- Mozilla Eats Babies for Lunch Pre-Pre-Alpha Developer Preview 0.0.0.1

- Target releases at web developers, not front-end testers.

- Boris proposes a *Gecko 1.9* alpha release in the near future to put
those major changes out to a wider testing audience. How this should
sync with FF2 releases is still under debate.

- Mike Connor proposes creating an update channel for Gecko testers,
pushing a new known-good trunk build every fortnight. Estimated freeze
time is one afternoon every two weeks for MozQA to run smoketests.

- Jonas notes that potential testers would not want to install an alpha


version that might wreck their bookmarks, eat their preferences and

stomp on their cookies. Changing install options so it doesn't write
to user's main FF profile might be a good idea.


My opinion:

- Plan a Gecko alpha release as Boris proposed in the first message.

- Call it "Gecko 1.9 Preview" or somesuch. The string should tie the
version number to "Gecko", not to "Gecko Browser".

- While FF development is still on the branch, don't worry too much about
syncing the releases, just make sure the front end on the trunk is stable
enough for the alpha release.

- Target the Gecko 1.9 release at web developers. Say this release is from
alpha development stages for the Firefox 3 *layout engine*, but it's still
using the same Firefox 2 front end as the FF2 builds. If testers are
interested in testing the latest layout engine from Mozilla, this is what
they should get. If they're only interested in Firefox and browsing
features, they should get the Firefox 2 branch releases.

- If we have the resources, also pick up Mike Connor's fortnightly update
channel idea. It'll make new layout engine developments that much more
easy and exciting (and thereby encourage more people to get involved with
bleeding-edge layout QA).

Basically, that follows two principles:
a) Don't try pushing the masses of testers around based on numbers.
Split them strategically based on how their skills/interests meet our
testing needs. People interested in layout engine improvements should
be poking at Gecko trunk. Everyone else should be poking at the FF2
branch.
b) Communicate clearly what the different testing builds mean.
Web developer-testers may want to have FF2 builds handy alongside
FF1.5 for testing their website for regressions, but focus on Gecko 1.9
when filing layout bugs. They can use builds more effectively if they
understand what's going on.

~fantasai

Andrew Schultz

unread,
Apr 14, 2006, 9:55:07 PM4/14/06
to
fantasai wrote:
> - Target releases at web developers, not front-end testers.

This line of reasoning is appealing (and would be ideal), but ignores
the fact that most bug reports (including layout engine bugs) are not
from web developers. They're mostly filed by users who know nothing
more than that the web page looks different than it does in IE or in the
previous version. I've probably seen about as many comments (HTML
comments by the developers) in web pages like "<!-- workaround for
Firefox -->" as I've seen bugs filed by web developers. Maybe they
assume that Firefox is defined to be "standards compliant" or maybe
they're just vastly outnumber by users.

So, we have to pitch a browser because the users don't care about the
layout engine.

What pitching to web developers /will/ get is people developing
next-generation web apps who want to take advantage of the
latest/greatest features included with Gecko 1.9. But I don't see that
as being enough.

--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/

Jonas Sicking

unread,
Apr 16, 2006, 1:26:40 AM4/16/06
to
>> So it might not be too bad to live with a regression a bit longer on
>> the trunk and make sure that we get a lot of testing at some point
>> well before we're approaching any sort of freeze.
>
> The problem is that if at that point we have a number of regressions
> that make the builds not testable by the general public then we have to
> do multiple alpha cycles as the regressions are discovered. If we start
> having alphas later, we'll have fewer alpha cycles, which will, imo,
> mean fewer regressions found.

OTOH, if we have too many alphas I think people will just think "i'll
just wait another alpha and test then, it should be more stable". I
guess the answer is to find the right number of alphas and make sure to
announce to the public what the purpose of each release is.

>> I think (someone correct me if i'm overly optimistic) that we're
>> keeping good enough quality through the nightly releases that we don't
>> have a lot of test-blocking level bugs.
>
> I think you're being overly optimistic. As a simple example, I'm
> currently using a February nightly for most of my browsing; there have
> been regressions almost constantly in various functionality areas since
> then, and the switch to Cairo makes our nightlies unusably slow on my
> computer (3-4 seconds to repaint the window after I do any window
> manager operation; 1-2 seconds to repaint when the window loses or gains
> focus).

Sure, but all this is stuff that the nightlies testing is finding, no?
It's just a matter of at some point deciding to focus on fixing it
before we ship an alpha.

My question remains, if we half-ass an alpha "since we havn't released
anything in 8 months", are we really going to get a lot of new testers
on it?

/ Jonas

Jonas Sicking

unread,
Apr 16, 2006, 2:08:25 AM4/16/06
to
>>> I think (someone correct me if i'm overly optimistic) that we're
>>> keeping good enough quality through the nightly releases that we
>>> don't have a lot of test-blocking level bugs.
>>
>> I think you're being overly optimistic. As a simple example, I'm
>> currently using a February nightly for most of my browsing; there have
>> been regressions almost constantly in various functionality areas
>> since then, and the switch to Cairo makes our nightlies unusably slow
>> on my computer (3-4 seconds to repaint the window after I do any
>> window manager operation; 1-2 seconds to repaint when the window loses
>> or gains focus).
>
> Sure, but all this is stuff that the nightlies testing is finding, no?
> It's just a matter of at some point deciding to focus on fixing it
> before we ship an alpha.

Actually, what I should say is, just because we find problems, it
doesn't mean that they will go away. We still have to actually fix them :)

I still think that if we just throwing more alphas out there is not
going to give us significantly higher quality than what the nightlies do.

/ Jonas

Boris Zbarsky

unread,
Apr 16, 2006, 1:16:15 PM4/16/06
to
Jonas Sicking wrote:
> I guess the answer is to find the right number of alphas and make sure to
> announce to the public what the purpose of each release is.

Exactly. For each one, list the new things that need testing.

> Sure, but all this is stuff that the nightlies testing is finding, no?

Could be; I have no idea. But the point is that if the builds are not usable
(say due to perf issues), then no one's going to test them (so we won't find
correctness bugs).

> It's just a matter of at some point deciding to focus on fixing it
> before we ship an alpha.

That point should be yesterday, imo.

> My question remains, if we half-ass an alpha "since we havn't released
> anything in 8 months", are we really going to get a lot of new testers
> on it?

My point is that we should schedule an alpha (and decide what remaining large
changes we'll take for it), then focus on getting this alpha usable so that we
can get useful testing from it. I suspect that'll take us another month or so
at least.

I'm not suggesting just shipping current trunk as-is. That would be rather
unfortunate.

-Boris

Mike Beltzner

unread,
Apr 17, 2006, 12:15:41 AM4/17/06
to Brendan Eich, Boris Zbarsky, dev-pl...@lists.mozilla.org, dev-pl...@lists.mozilla.org
On 4/15/06, Brendan Eich <bre...@meer.net> wrote:
> Mike Beltzner wrote:
> > I think it was mostly to reduce the pain of merging back to trunk from
> > a branch, as was experienced with aviary->gecko 1.8. That was the
> > rumour I heard or read off a bathroom wall or something, anyway ;)
>
> Hey look, I wrote up a bunch of reasoning, with a FAQ, at
> http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan. It talks
> explicitly about testing Gecko 1.9 with the Firefox 2 front end, to
> avoid the former regressing the latter.

Precisely the bathroom wall I was referring to, actually. :) FWIW, I
didn't mean to imply that I thought this was a poor approach. Quite
the opposite, really. I'm just trying to be careful about making
assertions about relative ease and complexity when I haven't really
got the history or context to make those sorts of statements.

> So it makes no sense to release "Gecko 1.9" as some kind of library set,
> even if we had frozen APIs in place for all app front ends to use (we
> don't). A trunk Firefox alpha, with appropriately obscure name, is
> absolutely necessary well before Firefox 2 ships.

So we're back to one of the options proposed earlier in this thread.

--
/ mike beltzner / user experience lead / mozilla corporation /

Mike Beltzner

unread,
Apr 17, 2006, 1:06:15 AM4/17/06