[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

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... ;)

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).

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

-Boris

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

Phil
--
Philip Chee <phi...@aleytys.pc.my>, <philip.c...@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

Makes sense, actually...

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

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

That will be excellent!

Rob

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_...

About 12 or these have some kind of  1.9a1  nomination or blocker flag
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_...

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_...

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.

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.  :(

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

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?

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

-Boris

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

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

Marcia added a2 as another bucket to throw things in for now.
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...

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).

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.

OK.  Who would?  Josh?

I meant removal of the gfx interfaces yeah.

That was more or less what I thought, yeah.

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.

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

That makes some sense to me.

-Boris

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 ]

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

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

Rob

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.  ;)

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

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

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

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 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

<...>

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.

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

Axel

Boris Zbarsky schrieb:

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