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

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

On Tue, 11 Apr 2006 12:34:31 -0500, Boris Zbarsky wrote:
> 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.

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

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

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

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

This is a multi-part message in MIME format.
--------------050109000101090608090003
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit

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=&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=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=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=&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-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>   


--------------050109000101090608090003
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=KOI8-R" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Robert O'Callahan wrote:
<blockquote cite="midhJSdnY-Fsogrh6HZnZ2dnUVZ_s6dnZ2d@mozilla.org"
 type="cite">
  <pre wrap="">Boris Zbarsky wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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?
  </pre>
</blockquote>
<br>
There are about 77 new bugs filed with the regression keyword in the
last 6 weeks.� Many owned by nobody.<br>
<a class="moz-txt-link-freetext" href="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=">https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=anywords&amp;keywords
=regression&amp;resolution=---&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailqa_contact2=1&amp;emailtype2=exact&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=2006-03-01&amp;chfieldto=Now&amp;chfield=%5BBug+creation%5D&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=</a><br>
<br>
About 12 or these have some kind of� 1.9a1� nomination or blocker flag<br>
<a class="moz-txt-link-freetext" href="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=flagtypes.name&type0-0-0=substring&value0-0-0=blocking1.9a1">https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keyword
s_type=anywords&amp;keywords=regression&amp;resolution=---&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailqa_contact2=1&amp;emailtype2=exact&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=2006-03-01&amp;chfieldto=Now&amp;chfield=%5BBug+creation%5D&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=flagtypes.name&amp;type0-0-0=substring&amp;value0-0-0=blocking1.9a1</a><br>
<br>
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.<br>
<br>
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.<br>
<a class="moz-txt-link-freetext" href="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=&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">https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=anywords&amp;keywords=regressi
on&amp;resolution=---&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailqa_contact2=1&amp;emailtype2=exact&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=flagtypes.name&amp;type0-0-0=substring&amp;value0-0-0=blocking1.9a1</a><br>
<br>
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<br>
<br>
chris h.<br>
<blockquote cite="midhJSdnY-Fsogrh6HZnZ2dnUVZ_s6dnZ2d@mozilla.org"
 type="cite">
  <pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:dev-planning@lists.mozilla.org">dev-planning@lists.mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://lists.mozilla.org/listinfo/dev-planning">https://lists.mozilla.org/listinfo/dev-planning</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------050109000101090608090003--

Benjamin Smedberg wrote:
> 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.

That will be excellent!

Rob

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

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

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

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

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

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

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

Chris Hofmann wrote:
> 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...

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

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

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

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"
:) ?

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

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

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

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

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

On 4/12/06, Benjamin Smedberg <benjamin@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.

cheers,
mike

--

[ mike beltzner / user experience lead / mozilla corporation ]

On 4/12/06, Benjamin Smedberg <benjamin@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.

cheers,
mike

--

[ mike beltzner / user experience lead / mozilla corporation ]

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

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

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
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

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

--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

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

--0F1p//8PRICkK4MW
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEPWRvA17gpBIYPJsRAikvAKDO1Qduylp/WJOwO+xyUoZF9uiaXwCgi+ie
KY2Cn58bT2TvgYjtGYY9Q6Q=
=YZey
-----END PGP SIGNATURE-----

--0F1p//8PRICkK4MW--

--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

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

--0F1p//8PRICkK4MW
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEPWRvA17gpBIYPJsRAikvAKDO1Qduylp/WJOwO+xyUoZF9uiaXwCgi+ie
KY2Cn58bT2TvgYjtGYY9Q6Q=
=YZey
-----END PGP SIGNATURE-----

--0F1p//8PRICkK4MW--

--qlTNgmc+xy1dBmNv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wednesday 2006-04-12 13:10 -0700, Chris Hofmann wrote:
> Its going to be tough to get any widespread testing of trunk snapshot=20
> builds named "minefield"...  I think that code name, or=20
> characterization, or branding for trunk builds is the wrong direction to=
=20
> be heading in.   We should be continuing to encourage and create a large=
=20
> development and testing community of  10,000 to 20,000 or more to help=20
> out in keeping the trunk as stable as possible at all times.  We should=
=20
> be and keeping destabilizing changes away from the trunk until they are=
=20
> baked and ready to land.  minefield sends the wrong message if these are=
=20
> still our goals.  This becomes harder the more branches we are working=20
> 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/0883b9=
b35d3400af
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.

-David

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

--qlTNgmc+xy1dBmNv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEPWirA17gpBIYPJsRArxFAJ9Rt1Li5M3NK0NSy2jUa1UYD0fvJQCgxCHu
1yvRgKGivuVQ/Z1kgVOFmyI=
=kIng
-----END PGP SIGNATURE-----

--qlTNgmc+xy1dBmNv--

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

On 4/12/06, Chris Hofmann <chofmann@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 beltzner / user experience lead / mozilla corporation ]

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

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

(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

On 4/12/06, Benjamin Smedberg <benjamin@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 / user experience lead / mozilla corporation ]

On 4/12/06, Benjamin Smedberg <benjamin@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 / user experience lead / mozilla corporation ]

On 4/12/06, L. David Baron <dbaron@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 t=
o
> > be heading in.   We should be continuing to encourage and create a larg=
e
> > 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 ar=
e
> > 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/0883=
b9b35d3400af
> 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?

cheers,
mike

--

[ mike beltzner / user experience lead / mozilla corporation ]

On 4/12/06, L. David Baron <dbaron@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 t=
o
> > be heading in.   We should be continuing to encourage and create a larg=
e
> > 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 ar=
e
> > 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/0883=
b9b35d3400af
> 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?

cheers,
mike

--

[ mike beltzner / user experience lead / mozilla corporation ]

On 4/13/06, Boris Zbarsky <bzbarsky@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
--

[ mike beltzner / user experience lead / mozilla corporation ]

On 4/13/06, Boris Zbarsky <bzbarsky@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
--

[ mike beltzner / user experience lead / mozilla corporation ]

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

--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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.

-David

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

--YiEDa0DAkWCtVeE4
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEPeaqA17gpBIYPJsRArUjAKDZW1yWi5ytQkbcvn9bZjcaQjHSNwCbBaQ+
RpJ3dzj2x4Km62FlSChH0To=
=X8TY
-----END PGP SIGNATURE-----

--YiEDa0DAkWCtVeE4--

--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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.

-David

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

--YiEDa0DAkWCtVeE4
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEPeaqA17gpBIYPJsRArUjAKDZW1yWi5ytQkbcvn9bZjcaQjHSNwCbBaQ+
RpJ3dzj2x4Km62FlSChH0To=
=X8TY
-----END PGP SIGNATURE-----

--YiEDa0DAkWCtVeE4--

On 4/13/06, L. David Baron <dbaron@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 te=
ns
> > > 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 porti=
on
> > > 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.

cheers,
mike

--

[ mike beltzner / user experience lead / mozilla corporation ]

On 4/13/06, L. David Baron <dbaron@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 te=
ns
> > > 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 porti=
on
> > > 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.

cheers,
mike

--

[ mike beltzner / user experience lead / mozilla corporation ]

--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thursday 2006-04-13 02:51 -0400, Mike Beltzner wrote:
> The way I see it, there are a couple of options:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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").

-David

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

--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEPfqGA17gpBIYPJsRAhUpAJ9aNnJUeADSVSlwoT9pSLSnRilJvwCfS5T8
gxaIuuj5zrbzK7KlBMdUhI4=
=bhZ4
-----END PGP SIGNATURE-----

--X1bOJ3K7DJ5YkBrT--

--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thursday 2006-04-13 02:51 -0400, Mike Beltzner wrote:
> The way I see it, there are a couple of options:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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").

-David

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

--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEPfqGA17gpBIYPJsRAhUpAJ9aNnJUeADSVSlwoT9pSLSnRilJvwCfS5T8
gxaIuuj5zrbzK7KlBMdUhI4=
=bhZ4
-----END PGP SIGNATURE-----

--X1bOJ3K7DJ5YkBrT--

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

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

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

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

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

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

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
ajschult@verizon.net
http://www.sens.buffalo.edu/~ajs42/

Mike Beltzner wrote:
> On 4/13/06, Boris Zbarsky <bzbarsky@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 ;)

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.

I'm late to the thread so I won't flame anyone, but it should be clear 
by now that our continuously integrating trunk exists entirely so we can 
find all the hard bugs (which bite us constantly) the hide everywhere 
(front-end, back-end, in between, in both places).  Modularity is not 
sufficient, and it's kind of a myth in a single address space app coded 
in type- and memory-unsafe low-level programming languages.

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.

/be

L. David Baron wrote:

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

And when there are not lots of CVS revisions dogpiled on top, entangling 
with the regressing change in arbitrarily complex ways.  It's bad enough 
to have to do "CVS archeology" or binary-search-testing of old builds. 
Having to disentangle merged code is even worse.  So time in regression 
finding and fixing is of the essence.

/be

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

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

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

On 4/15/06, Brendan Eich <brendan@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 /

On 4/15/06, Brendan Eich <brendan@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 /

On 4/14/06, fantasai <fantasai.lists@inkedblade.net> wrote:
> Ok, so here's what I'm understanding so far. Correct me if I'm wrong.

[..snip..]

Great round up, Fantasai. That seems to be pretty right to me, in
terms of summary, and I like the recommendations you make in terms of
clearly communicating what the various releases would be for.

As Andrew mentions, focusing the release on web developers might not
get the critical mass for testing that bz and dbaron are looking for.
I think it's important to communicate the idea that the front end of
Gecko 1.9 releases won't diverge meaningfully from Firefox 2 until the
latter has been released in its final form, but more to manage
expectations of reviewers who might otherwise wonder why the two are
so identical looking at the level of the chrome.

I must once again question the idea of a named, branded release, as
opposed to a milestone (ie: dated) checkpoint for which we can make
assertions of stability of the code. This avoids the introduction of a
new name (f.e. Gecko Browser, Gecko, Firefox 3, etc) and allows us to
clearly message about how, for example, "Minefield Stable
(2006-05-15)" is a for-tester release of the next Gecko layout engine,
using the same UI as exists in Firefox 2, and so testers should feel
free to use it or the latest Bon Echo release for their testing
depending on the criteria you listed.

cheers,
mike


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

fantasai wrote:
>       -> bz is compiling a list of these

I've posted the current state of what I know about at 
<http://wiki.mozilla.org/Gecko_1.9_Alpha_Planning>.  I crave feedback or direct 
wiki edits.

My impression is that the long pole in the whole thing is the combination of 
cocoa widgets, followed by cairo on Mac, followed by the nsTextFrame changes 
(likely needed to get perf parity with pre-cairo).  I suspect we'll want to put 
alpha 1 somewhere in the middle of that long pole; the question is where.  I'd 
like it to be after we enable cairo on Mac, but we need more timing information 
here.

-Boris

I found this thread trying to find the status of the trunk.  I'm one of
your bleeding-edge users that was on DeerPark 1.6a1 with the
channel-prefs.js hack to get nightly updates, and I've been waiting for
a flashing amber light to get back on the trunk ever since that stopped
updating.  (The unchanging Bon Echo 2.0a1 just isn't doing it for me
:-)

I applaud fantasai's summary.  I like mconnor's idea for a
"bruised-edge" update channel, or if that's too much work, just an
occasional "Last night's build seems OK" blog or forum post.

Naming is tricky when you've got Firefox 1.5.xx, Firefox 2 "Bon Echo",
and Gecko 1.9 as candidates for user testing.  But no matter how you
characterize a "Minefield 1.9 engine preview alpha" release, some site
will link directly to its bits with a "Firefox 3 is out!!!" headline,
so all you can do is warn users *away* from it in all its splash screen
/ Help -> About / Release Notes / Check for Updates messaging.

I strongly agree with "Communicate clearly what the different testing
builds mean"; as small help I've added clarifying text and links on
some of the Firefox3/Gecko 1.9 wiki pages.

Good luck with the alpha.

On 17 Apr 2006 19:15:21 -0700, skierpage@gmail.com <skierpage@gmail.com> wr=
ote:
> updating.  (The unchanging Bon Echo 2.0a1 just isn't doing it for me
> :-)

Software updates for Bon Echo were re-enabled on March 14th, fwiw. :)

> I strongly agree with "Communicate clearly what the different testing
> builds mean"; as small help I've added clarifying text and links on
> some of the Firefox3/Gecko 1.9 wiki pages.

Good idea. Thanks.

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

Jonas Sicking wrote:
> 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.

This is contradicted by our experience over the years, especially during 
the push to Firefox 1.0 when 1.8 alpha lingered on the trunk.  But we 
have always had problems with regressions diving deep, entangling with 
other changes.

What you write above "live with a regression a bit longer" implies that 
regressions are known and tracked, and fixing them can be deferred. 
That is not the case.  Too often, regressions are not even *found* until 
an alpha-scale (100k+ downloads) release is done -- and then the hard 
job of diagnosing begins.  This can take months.

/be

skierpage@gmail.com wrote:
> But no matter how you
> characterize a "Minefield 1.9 engine preview alpha" release, some site
> will link directly to its bits with a "Firefox 3 is out!!!" headline,

I think that anytime you use the terms "alpha', "beta", or "preview", 
you invite this type of confusion.

Leave "alpha', "beta", or "preview" to product releases and characterize 
offerings straight from the truck as "snapshots."  I've seen that term 
used previously in this thread.  It better describes what such an 
offering is or, at the very least, will beg authors to investigate and 
then hopefully explain the term to their audience.  Hence:

Firefox 2.0 Developer Preview
Firefox 2.0 Beta1
Minefield Snapshot 20060515
Minefield Snapshot 20060615
Firefox 3.0 Developer Preview
Firefox 3.0 Beta1

Ian Pottinger wrote:
> Leave "alpha', "beta", or "preview" to product releases and characterize 
> offerings straight from the truck as "snapshots."

Except the point is that this IS a "developer preview" of Gecko 1.9.  That's why 
we're doing it.

Now whether we should call it a "preview" of Firefox 3 is a different issue.

-Boris

OK, so looking at http://wiki.mozilla.org/Gecko_1.9_Alpha_Planning I'm starting 
to think that one thing we should consider is shipping an alpha 1 in the next 
few weeks (at the same time as the aforementioned 2.0 beta?) with cairo disabled 
on either all platforms or just Mac (depending on the state of cairo at that 
point and on our estimate of how much the cairo regressions would interfere with 
testing).

To make that decision, we need to start actually tracking the cairo regressions, 
of course, both performance and correctness (possibly under separate trackers, 
so two trackers per platform or something).  If desired, we could track 
correctness on the "enable cairo by default" bugs, of course.

Did we ever get bugs filed to do this tracking?  If not, would someone be 
willing to do so and start adding dependencies?  It would be very helpful.

-Boris

fantasai wrote:
>   - 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".)
At this point, I'd want to avoid targeting bugs for that far in the 
future, since you can easily end up with other bugs depending on broken 
behaviour, and that can chain fairly fast, making fixing the underlying 
issue a game of Wac-A-Mole.
>   - 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.
This is fairly easy to do, we've avoided it in the past, but its 
probably worth looking at for the trunk.
>     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.
I think the key here is "interested" users.  I don't classify this as 
meaning "web developers" to the exclusion of others, but I think that 
lots of people are interested in what happens on trunk, and the update 
channel concept would remove a big barrier to entry for the 
not-quite-bleeding-edge group, and possibly, if we do a good enough job 
with those, we'll get a wide enough spread to catch more bugs faster.
>     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.
It'd be handy to have a nice chart somewhere on mozilla.org showing all 
current development tracks, where to get latest releases/stable 
builds/nightlies.  This would have 1.5.0.x/Bon Echo/Minefield for the 
browser at least.

-- Mike

skierpage@gmail.com schrieb:
> Naming is tricky when you've got Firefox 1.5.xx, Firefox 2 "Bon Echo",
> and Gecko 1.9 as candidates for user testing.  But no matter how you
> characterize a "Minefield 1.9 engine preview alpha" release, some site
> will link directly to its bits with a "Firefox 3 is out!!!" headline,
> so all you can do is warn users *away* from it in all its splash screen
> / Help -> About / Release Notes / Check for Updates messaging.

If the UA string would show "Minefield/20060528" instead of 
"Firefox/3.0a" this might be less the fact...
And that would be another test for web pages, as mayn pages currently 
test for "Firefox/" in the UA string, and close out all other 
Gecko-based browsers that would work.
Usually, this is something that users of Camino or SeaMonkey are seeing, 
but such a UA change might shed some more light on those cases (not sure 
if that's reall wanted though).

Robert Kaiser

On 4/18/06, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> to think that one thing we should consider is shipping an alpha 1 in
> the next few weeks (at the same time as the aforementioned 2.0 beta?)

Aforementioned 2.0 Alpha, you mean. The planned ship date for Bon Echo
Alpha 2 is May 9th. I think to get the best testing coverage and
exposure, you'd want to release a Minefield
Snapshot/Milestone/Whatever  the week after that. Gets you another
media cycle.

cheers,
mike

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

Robert Kaiser wrote:
> Usually, this is something that users of Camino or SeaMonkey are seeing, 
> but such a UA change might shed some more light on those cases (not sure 
> if that's reall wanted though).

It's wanted by me.

-Boris

Mike Connor wrote:
> fantasai wrote:
>>     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.
> I think the key here is "interested" users.  I don't classify this as 
> meaning "web developers" to the exclusion of others, but I think that 
> lots of people are interested in what happens on trunk, and the update 
> channel concept would remove a big barrier to entry for the 
> not-quite-bleeding-edge group, and possibly, if we do a good enough 
> job with those, we'll get a wide enough spread to catch more bugs faster.
>>     

We really do need to push folks around and draw them to test gecko based 
where the focus can be of the highest value.   There are back end 
changes going into 2.0 and they need to be shaken out at some point as 
well...  

http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-04#Infrastructure:_Platform_Uplift

By the time these 23 approved and 110 nominations are dealt with on the 
1.8.1 branch there will be need to shake those out.  More nominations 
will follow during 2.0 development...

23 approved so far
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=allwords&keywords=&resolution=DUPLICATE&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.8.1%2B

110 nominations
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=allwords&keywords=&resolution=DUPLICATE&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.8.1%3F

The key to all this testing is to get a pretty good set of builds though 
lots of focus bug triage and testing by some very active testers, then 
draw 100,000+ into the mix to shake out more obscure problems.  This 
will be needed on both the 1.8.1 branch and trunk.

chris h.

Mike Beltzner wrote:
> Aforementioned 2.0 Alpha, you mean. The planned ship date for Bon Echo
> Alpha 2 is May 9th.

OK.  So are there major landing owners who are not reading this?  ;)  If you 
know of one, poke them.  I'd like to see date estimates for all landings, to the 
extent that that's possible.  That will tell us where we stand.

-Boris

Chris Hofmann wrote:
> There are back end 
> changes going into 2.0 and they need to be shaken out at some point as 
> well... 

I should note that if we were testing reasonably on trunk we'd have a lot less 
to worry about in terms of 2.0 at this point, imho, since all those changes are 
landing on trunk first, often by weeks.

-Boris

Boris Zbarsky wrote:
> Chris Hofmann wrote:
>> There are back end changes going into 2.0 and they need to be shaken 
>> out at some point as well... 
>
> I should note that if we were testing reasonably on trunk we'd have a 
> lot less to worry about in terms of 2.0 at this point, imho, since all 
> those changes are landing on trunk first, often by weeks.
Yes, but those patches are landing on top of other patches on trunk, 
which may not be making it to the branch for various reasons, and the 
interactions are thus different.  We hit that a fair bit in the endgame 
for 1.5, and hopefully we can learn from that and not shortchange the 
amount of testing for branch Gecko changes.

-- Mike

Boris Zbarsky wrote:
> OK, so looking at http://wiki.mozilla.org/Gecko_1.9_Alpha_Planning I'm 
> starting to think that one thing we should consider is shipping an 
> alpha 1 in the next few weeks (at the same time as the aforementioned 
> 2.0 beta?) with cairo disabled on either all platforms or just Mac 
> (depending on the state of cairo at that point and on our estimate of 
> how much the cairo regressions would interfere with testing).
>
> To make that decision, we need to start actually tracking the cairo 
> regressions, of course, both performance and correctness (possibly 
> under separate trackers, so two trackers per platform or something).  
> If desired, we could track correctness on the "enable cairo by 
> default" bugs, of course.
>
> Did we ever get bugs filed to do this tracking?  If not, would someone 
> be willing to do so and start adding dependencies?  It would be very 
> helpful.
I searched though bugs with "cairo" in the title and couldn't see any 
top level trackers so I filed this
https://bugzilla.mozilla.org/show_bug.cgi?id=334509

With performance and correctness under dependency bugs

performance clean up- https://bugzilla.mozilla.org/show_bug.cgi?id=334510
correctness clean up- https://bugzilla.mozilla.org/show_bug.cgi?id=334512

the pool of "cairo" titled bugs is a good place to start in finding bugs 
that need to be linked in to these.

chris .
>
> -Boris
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Mike Connor wrote:
> Yes, but those patches are landing on top of other patches on trunk, 
> which may not be making it to the branch for various reasons, and the 
> interactions are thus different.  We hit that a fair bit in the endgame 
> for 1.5, and hopefully we can learn from that and not shortchange the 
> amount of testing for branch Gecko changes.

Of course imho we should also be limiting branch Gecko changes, generally 
speaking...  Not just in terms of "this is a scary arch change" but in terms of 
"this changes behavior from web authors' point of view".

-Boris

Chris Hofmann wrote:
> top level trackers so I filed this
> https://bugzilla.mozilla.org/show_bug.cgi?id=334509
> 
> With performance and correctness under dependency bugs
> 
> performance clean up- https://bugzilla.mozilla.org/show_bug.cgi?id=334510
> correctness clean up- https://bugzilla.mozilla.org/show_bug.cgi?id=334512

I assume those are for Cairo-windows?  We probably want to track each of the 
three platforms separately, since so many of the regressions are 
platform-specific and need platform-specific fixes....

-Boris

(I'm kind of late to this thread and still not done catching up, oh well 
:-/)

Mike Connor wrote:
> 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).

You earlier mentioned that you wouldn't tag them/make source tarballs 
available. In my opinion, everything that lands in a /release/ directory 
should have a corresponding tag and source tarball - since this is an 
open-source project, the source for all releases ought to be easily 
available.

On 4/18/06, Christian Biesinger <cbiesinger@web.de> wrote:
> You earlier mentioned that you wouldn't tag them/make source tarballs
> available. In my opinion, everything that lands in a /release/ directory
> should have a corresponding tag and source tarball - since this is an
> open-source project, the source for all releases ought to be easily
> available.

Would we want this in a releases/ directory?  Seems to me that we
wouldn't, if we could easily avoid it.  But tagging it seems virtuous,
and source tarballs are part of the nightly machinery already, so
those seem like reasonable desires both.

Mike

skierpage@gmail.com wrote in news:1145326521.849409.212180
@j33g2000cwa.googlegroups.com:

> I found this thread trying to find the status of the trunk.  I'm one of
> your bleeding-edge users that was on DeerPark 1.6a1 with the
> channel-prefs.js hack to get nightly updates, and I've been waiting for
> a flashing amber light to get back on the trunk ever since that stopped
> updating.  (The unchanging Bon Echo 2.0a1 just isn't doing it for me
>:-)

I'm another bleeding-edge user, I've been using trunk on my laptop but 
I've hung onto an old pre-Places February branch build on my desktop 
because I don't fully trust Places not to wreck my bookmarks and so 
forth; I agree with Jonas that that's an obstacle to getting people to 
test unstable builds. I'm not sure what the best solution to that is 
though; IMO it would be useful to have some kind of a lightweight "Gecko 
in a box" kiosk-type build that doesn't use a profile at all and can be 
run concurrently with a stable Firefox, for people who just want to try 
out websites with the new rendering engine. Of course we do want people 
to test Places....

> I strongly agree with "Communicate clearly what the different testing
> builds mean"; as small help I've added clarifying text and links on
> some of the Firefox3/Gecko 1.9 wiki pages.

I think it's also going to be important to communicate right up front in 
the announcement any obvious known bugs that are going to be in these 
releases, in a way similar to the "red list" in Peter(6)'s posts in the 
MozillaZine Firefox Builds forum. For example, there's a big list of 
Cairo bugs that probably aren't all going to be fixed in a month, and 
which aren't necessarily easy to find by searching for symptoms, so we're 
probably just going to get a big pile of dupes on those if we just tell 
people "grab this and look for bugs", and many testers probably won't 
bother to look past the obvious bugs. Bug 324706 in particular has been 
getting lots of dupes even just with the nightly testers.

Acknowledging the obvious bugs up front is also more likely to get 
understanding and support from users rather than a stream of "wow this is 
hilariously broken, good luck pulling this together in time for Fx3" blog 
comments.

--
DopefishJustin@MailandNews.com is spambait
dopefish justin at gmail dot com
http://interbutt.com/

Mike Shaver wrote:
> Would we want this in a releases/ directory?  Seems to me that we
> wouldn't, if we could easily avoid it. 

Yeah, what I mainly meant was that if this is just a glorified nightly 
(as mconnor suggested in pushing this via the update system only), then 
having tags/source tarballs probably isn't so important.

> But tagging it seems virtuous,
> and source tarballs are part of the nightly machinery already, so
> those seem like reasonable desires both.

But I'm glad you agree :-)

Mike Beltzner wrote:
> On 4/14/06, fantasai <fantasai.lists@inkedblade.net> wrote:
>> Ok, so here's what I'm understanding so far. Correct me if I'm wrong.
> 
> [..snip..]
> 
> Great round up, Fantasai. That seems to be pretty right to me, in
> terms of summary, and I like the recommendations you make in terms of
> clearly communicating what the various releases would be for.
> 
> As Andrew mentions, focusing the release on web developers might not
> get the critical mass for testing that bz and dbaron are looking for.

I'm interpreting this more the way mconnor does:
   | I think the key here is "interested" users.  I don't classify this
   | as meaning "web developers" to the exclusion of others, but I think
   | that lots of people are interested in what happens on trunk

By target web developers, I mean put the notices prominently where they
will notice, but do ask for _anyone_ interested in testing the FF3 back
end.

Say somewhere that this means the core part of the browser will be less
stable than the branch builds. Some people might want to stay away from
the trunk release because of that, others will be drawn to it nonetheless
because it's the Core of the future. The tester should be able to make
his/her decision based on that understanding.

> I think it's important to communicate the idea that the front end of
> Gecko 1.9 releases won't diverge meaningfully from Firefox 2 until the
> latter has been released in its final form, but more to manage
> expectations of reviewers who might otherwise wonder why the two are
> so identical looking at the level of the chrome.

Yes, that's important. Basically, the three bits of information we *need*
people to understand about the alpha release are
    a) this Gecko alpha thing is a preview of the FF3 *back end*
    b) it uses the *same front end* as the FF2 branch builds
    c) because of a) its back end is less stable than the FF2 branch builds

> I must once again question the idea of a named, branded release, as
> opposed to a milestone (ie: dated) checkpoint for which we can make
> assertions of stability of the code. This avoids the introduction of a
> new name (f.e. Gecko Browser, Gecko, Firefox 3, etc) and allows us to
> clearly message about how, for example, "Minefield Stable
> (2006-05-15)" is a for-tester release of the next Gecko layout engine,
> using the same UI as exists in Firefox 2, and so testers should feel
> free to use it or the latest Bon Echo release for their testing
> depending on the criteria you listed.

Minefield Stable is an oxymoron. :)

Again, it's all about communication. The purpose of this release is to
focus on testing *Gecko*. Reflecting that purpose in its name makes it
that much clearer to testers why this release exists and what it's for.

We can resurrect the "viewer" term, if you'd rather.

   "Gecko 1.9 Alpha 1 Viewer"
    ^^^^^^^^^^^^^^^^^ --|-- Gecko name/version first
                        \
                          Application type second

   It's a viewer/browser/whatever for Gecko 1.9 Alpha 1, not a
   viewer/browser/whatever branded with "Gecko".

~fantasai

Brendan Eich wrote:
> Jonas Sicking wrote:
>> 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.
> 
> This is contradicted by our experience over the years, especially during 
> the push to Firefox 1.0 when 1.8 alpha lingered on the trunk.  But we 
> have always had problems with regressions diving deep, entangling with 
> other changes.
> 
> What you write above "live with a regression a bit longer" implies that 
> regressions are known and tracked, and fixing them can be deferred. That 
> is not the case.  Too often, regressions are not even *found* until an 
> alpha-scale (100k+ downloads) release is done -- and then the hard job 
> of diagnosing begins.  This can take months.

My experience has actually been that we don't find bugs until we do a 
largely trumpeted beta, or even RC. But it seems like this is not the 
experience other people have had so I will stand down in that regard.

However I think still think we need to work on reaching a larger 
audience with our pre-releases. And do it at a time when there is still 
room to make risky fixes (i.e. before beta).

/ Jonas

Jonas Sicking wrote:

> My experience has actually been that we don't find bugs until we do a 
> largely trumpeted beta, or even RC. But it seems like this is not the 
> experience other people have had so I will stand down in that regard.

No argument that an even wider (by a decimal order) release gets even 
more feedback on harder-to-find corner cases.

We need to scale up.  We should not skip alpha and hope to unregress all 
the bugs we would have fixed by doing alphas, plus all the 
harder-to-find beta bugs, when we do a first 1.9 beta.

> However I think still think we need to work on reaching a larger 
> audience with our pre-releases. And do it at a time when there is still 
> room to make risky fixes (i.e. before beta).

Agreed.

/be

On Tue, 18 Apr 2006 21:52:59 UTC, Christian Biesinger wrote:

> Mike Shaver wrote:
> > Would we want this in a releases/ directory?  Seems to me that we
> > wouldn't, if we could easily avoid it. 
> 
> Yeah, what I mainly meant was that if this is just a glorified nightly 
> (as mconnor suggested in pushing this via the update system only), then 
> having tags/source tarballs probably isn't so important.

But then it should at least be clear which date/time we have to use on 
the cvs commandline to check out the same code to be able to built for 
alternative platforms (which I assume should be done for the same 
reasons as for the tier 1 platforms).
-- 
Greetings,
   Peter.

Chris Hofmann wrote:
> I searched though bugs with "cairo" in the title and couldn't see any 
> top level trackers so I filed this
> https://bugzilla.mozilla.org/show_bug.cgi?id=334509

I went ahead and filed the per-platform bugs so we can track each 
platform separately; if we're going to consider shipping cairo on some 
platforms but not others, we'll need that.  :(

-Boris

On 4/19/06, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Chris Hofmann wrote:
> > I searched though bugs with "cairo" in the title and couldn't see any
> > top level trackers so I filed this
> > https://bugzilla.mozilla.org/show_bug.cgi?id=3D334509
>
> I went ahead and filed the per-platform bugs so we can track each
> platform separately; if we're going to consider shipping cairo on some
> platforms but not others, we'll need that.  :(

I don't think the SVG-is-slow-because-of-Cairo bugs should be in this
tree; we should be using this to track regressions associated with
switching to cairo-based gfx, not "all uses of cairo".

Mike

Mike Shaver wrote:
> I don't think the SVG-is-slow-because-of-Cairo bugs should be in this
> tree; we should be using this to track regressions associated with
> switching to cairo-based gfx, not "all uses of cairo".

Er... yes. I thought I'd removed those from the dep list...  Will do so now.

-Boris

Boris Zbarsky wrote:
> Chris Hofmann wrote:
>> I searched though bugs with "cairo" in the title and couldn't see any 
>> top level trackers so I filed this
>> https://bugzilla.mozilla.org/show_bug.cgi?id=334509
>
> I went ahead and filed the per-platform bugs so we can track each 
> platform separately; if we're going to consider shipping cairo on some 
> platforms but not others, we'll need that.  :(
>
You are right if we are going to try break support on the platforms like 
this.  It has been a long time since we have needed to do something like 
that, and I think experience showed that going down that road created 
more problems that it was worth.  Brendan can weigh in on the bad old 
days when Unix and Mac stuff shipped months after windows and the 
problems it caused in trying to unify content support by web developers 
and a whole host of other problems.  If we can get to something that 
approaches platform partity soon I think that should be the focus.  
Maybe the "by platform" tracking bugs will help that.

Pav and vlad are going to try and make it to the content meeting 
tomorrow so we can talk about it more and try and make some more 
progresss on the branch landing and alpha planning.

Thursday 11:00a PDT

Call in numbers are
866.489.0573  or 205.354.0119 intl
passcode *8660257*

> -Boris
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Chris Hofmann wrote:
> If we can get to something that 
> approaches platform partity soon I think that should be the focus.  

Oh, I agree.  But if the schedule for cairo on mac looks like "months" 
(which is what I see right now), or if one of the two platforms that's 
enabled has major perf or correctness issues, and if we want an alpha 
out asap to test everything else, then we're deciding between disabling 
cairo across the board, shipping cairo on some platforms but not others, 
or shipping an alpha much later.  Just figured it'd be good to have an 
idea of how all that stands.

> Pav and vlad are going to try and make it to the content meeting 
> tomorrow so we can talk about it more and try and make some more 
> progresss on the branch landing and alpha planning.

Mac cairo is blocked on cocoa widgets at the moment anyway.  It sounds 
like it'll be at least a few weeks before those can possibly land, much 
less stabilize...

-Boris

Robert Kaiser wrote:
> If the UA string would show "Minefield/20060528" instead of
> "Firefox/3.0a" this might be less the fact...

We absolutely do not want the UA to say Firefox-anything until it's
ready for Firefox end-users.

Dan Veditz wrote:
> Robert Kaiser wrote:
> 
>>If the UA string would show "Minefield/20060528" instead of
>>"Firefox/3.0a" this might be less the fact...
>  
> We absolutely do not want the UA to say Firefox-anything until it's
> ready for Firefox end-users.

Mmm, naming. How about "Foundation"?

"Mozilla/5.0 (Windows...en-US rv:N.N) Gecko/20060308 Foundation/1.9a1"

-Rob

--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tuesday 2006-04-18 19:40 +0200, Robert Kaiser wrote:
> skierpage@gmail.com schrieb:
> >Naming is tricky when you've got Firefox 1.5.xx, Firefox 2 "Bon Echo",
> >and Gecko 1.9 as candidates for user testing.  But no matter how you
> >characterize a "Minefield 1.9 engine preview alpha" release, some site
> >will link directly to its bits with a "Firefox 3 is out!!!" headline,
> >so all you can do is warn users *away* from it in all its splash screen
> >/ Help -> About / Release Notes / Check for Updates messaging.
>=20
> If the UA string would show "Minefield/20060528" instead of=20
> "Firefox/3.0a" this might be less the fact...
> And that would be another test for web pages, as mayn pages currently=20
> test for "Firefox/" in the UA string, and close out all other=20
> Gecko-based browsers that would work.
> Usually, this is something that users of Camino or SeaMonkey are seeing,=
=20
> but such a UA change might shed some more light on those cases (not sure=
=20
> if that's reall wanted though).

It would be significantly easier to maintain if we just did
"Minefield/3.0a", since then we can do it purely based on variables that
already exist.  I've filed
https://bugzilla.mozilla.org/show_bug.cgi?id=3D334756 on doing this.

-David

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

--Kj7319i9nmIyA2yE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFERsalA17gpBIYPJsRAvr6AKDLqpS/9GUleTH55VGak7XUv7QzQQCgoxHu
kmNP//0lHZdMyBsPMWpSFxA=
=ADv9
-----END PGP SIGNATURE-----

--Kj7319i9nmIyA2yE--

So I was just told about this thread for the first time, so sorry I'm
late to the game.

I think shipping an alpha in May is a bad idea.  We're shipping Firefox
2.0 alphas and many people will be gone to XTech for at least a week.
I think June or July for an alpha at the earliest. People need advanced
notice to wrap things up and fix alpha-level bugs, and giving people
around a month just isn't enough time.  This will certainly have to be
scheduled with the build team as well to see when they have time for
it.

We're working on getting Cocoa widgets done and mac cairo on.  It'll
probably happen sometime in the next couple weeks, which puts us in
early May.  I suspect there will be some set of regressions, both from
cairo on mac and from cocoa widgets on mac.  There are a lot of subtle
event bugs in the cocoa widget code now and I suspect we won't catch
them all.

Disabling cairo for the alpha (on any platform) seems like a no-start
to me.  We should hold the alpha imho if some things aren't ready or
need a little more work.  The cairo stuff is the biggest change in
Gecko and needs just as many eyes on it as everything else.  In
general, I don't think the cairo changes cover up any other gecko
changes (maybe some of the displaylist stuff), but we _are_ moving to
cairo.  Rather than saying there are problems and we shouldn't ship
with it, I'd suggest actually jumping in and trying to help fix them.

stuart

Robert Sayre wrote:
> Mmm, naming. How about "Foundation"?
> 
> "Mozilla/5.0 (Windows...en-US rv:N.N) Gecko/20060308 Foundation/1.9a1"

Or that part could just be removed from the useragent string... the 
1.9a1 part is already in the rv: string.

Figured folks should know what our testing situation on trunk and branch looks 
like to some who're doing it.  They've been pretty under-represented in this 
discussion.

As a result of the discussion at 
http://www.squarefree.com/burningedge/2006/04/17/thread-about-trunk-alphas/ I 
got mail today from someone who's been organizing trunk build testing in the 
mozillazine forums.  He wasn't quite confident enough to post here himself for 
some reason, but he did say I could quote his mail as needed.

Note that I'm not necessarily endorsing all of this, but it gives food for thought.

Here are some relevant parts (I removed some of the self-deprecation, since it's 
not really relevant; but keep in mind that it was there):

--------------------------------------------------------------------------------
Re: trunk vs 1.8 branch testing:

"I also asked various people where I should take the hardcore group of testers 
that communicate on the forum, trunk or branch , and no one was able to give me 
an answer nor an argument for choosing. I picked Trunk and I'm glad I did, we 
caught untold amounts of bugs before they were released on Branch, but with more 
and more simultaneous check ins for major core changes more and more are 
slipping by.  How long has it been since split:window landed ? Four month, and I 
still see the odd NEW bug being added to the list of dependencies. And 
split:windows happened on it's own, in a period that not too many other greater 
changes happened."

--------------------------------------------------------------------------------
Re: things landing on 1.8 branch after being baked on trunk (specifically the 
amount of baking):

"Yes, it's not long enough, there are so many simultaneous changes and so many 
mid check ins that initially minor stuff isn't reported. We just check what the 
next build will is like... and the few after that.
Even pointing at a cause is often hard enough for a coder, let alone for people 
like me, who judge based on instinct."

--------------------------------------------------------------------------------
Re: state of trunk:

"e.g. Core:Layout can easily be a regression from Thebes and we've so far been 
extremely gentle for Vlad/Stuart by not overreacting to little mishaps and just 
leaving them to gradually work their way through the pile. Off course their 
current pile is 99% on getting cairo running on Linux and Mac and it would only 
be extremely counterproductive if we would whine like a bunch of kids about one 
or another font that isn't really displayed like it used to be. If the layout 
bug isn't caused by Thebes, and we find out weeks later (if at all), the 
potential damage is already done and getting the right person on it will be a 
lot harder"

"It's the variety of changes that make this so tough."

--------------------------------------------------------------------------------
Re: testing load and time commitment:

"For trunk, doing Places and Thebes simultaneously is just about what we can 
handle, it would be far more efficient if these things could be landed and fixed 
one at the time.
This would mean that every alpha release would have to be a feature complete for 
1 component.
If a number of features have landed we'll just stop, fix a few mishaps and 
security stuff and done.
The only pressure would come from groups that do different parts of the code and 
are anxiously waiting to land their stuff, if they want that to happen rather 
sooner than later the only option would be to actually help finish the alpha first."

[editor's (bz's) note:  I'm not sure this is feasible, given that we do develop 
in parallel and all]

--------------------------------------------------------------------------------
Re: scheduling of releases

"The 100% difference with now is that alpha's and beta's have proven to be 
incomplete and often have to be rushed to a half-end because someone puts down 
its foot and says it's time for release.
FF1.0 regressions/features still haven't been fixed, FF1.5 regressions/features 
still haven't been fixed and this just keeps adding up"

[editor's note: This is sort of what I'm doing right now, and I wish we'd had 
this discussion back in January, but we were all too fried with 1.8 and then 
security releases.]

-Boris

> Re: scheduling of releases
> 
> "The 100% difference with now is that alpha's and beta's have proven to 
> be incomplete and often have to be rushed to a half-end because someone 
> puts down its foot and says it's time for release.
> FF1.0 regressions/features still haven't been fixed, FF1.5 
> regressions/features still haven't been fixed and this just keeps adding 
> up"
> 
> [editor's note: This is sort of what I'm doing right now, and I wish 
> we'd had this discussion back in January, but we were all too fried with 
> 1.8 and then security releases.]

I think one important point here, and in Stuarts recent posting is that 
it might be better to base pre releases on features rather than points 
in time. I.e. if we want to release an alpha to get testing on a set of 
changes that has landed, we should make sure that those changes are 
landed and somewhat baked before we release. Otherwise we don't get the 
desired result from the release.

Of course, it's easy for that to turn into a slippery slope where final 
releases are based on features rather then schedule which I think would 
be a bad idea. However release dates usually does, and IMHO should, move 
a little bit depending on when certain features land and stabalize.

/ Jonas