Scheduling a trunk alpha
Boris Zbarsky
Now that we've convinced people that FF 3 alpha is not out yet, let's figure out
when we _do_ plan to have a trunk alpha. The 1.8 branch branched on August 12,
2005; tomorrow it will be 8 months since that day. That's 8 months of trunk
development already; for comparison, by this point in the 1.8 Gecko cycle we had
already done the 1.8a5 release. Granted, the alphas weren't getting much
testing because of all the effort focused on Aviary, but we _did_ see a spike in
useful bug reports around each alpha being released.
I'm not sure what the thinking is about checkpointing trunk and calling it an
alpha and what the build team costs of doing an alpha release are, but I can
understand us not wanting to ship an alpha quite yet. At the same time, we've
made some pretty big changes (DOM event dispatch, frame display lists, 2/3 of
cairo) that could use testing.
We probably shouldn't ship an alpha until we turn on cairo by default on Mac.
But after that (hopefully soon?) point, what else do we need or want to wait
for? What other large projects are scheduled for 1.9 at this point? I can
think of reflow branch, view removal, widget removal, nsTextFrame rewrite, gfx
removal off the top of my head. Do we want all those done before we ship an
alpha? Or some subset of those? Are we OK with landing some of these after the
first alpha (and do we plan to have multiple alpha releases)? Are there things
I'm forgetting?
One last note: naming. I have no particular yen to have this be named "Firefox
3 Alpha 1". Let's make up a codename if we don't have one yet and ship this as
"Codename Developer Preview 1" or something. Make it clear that this is
pre-alpha (not all large features done) and list the specific large changes we
made that we'd like testing from web developers on...
One last note. As I recall, IE7 made "releases" similar to this "developer
preview" thing I'm suggesting -- before they ever got to beta they were doing
random development snapshots every so often. I realize we do that every day,
but that regularity itself means there's not as much "cool" factor to it as a
"finally, something they've let us have a glimpse at" thing like IE7 snapshots.
I wonder whether we could get a bigger testing audience with something that we
not only put on the FTP server but also mention on some blogs, the mozilla.org
web site (NOT mozilla.com), etc.
Thoughts?
-Boris
schiller
the nightly trunk builds are called starting 04-11. "Mozilla Minefield
Pre-Alpha Developer Preview 1" sounds a little scary though... ;)
Boris Zbarsky
> Isn't the codename for Firefox 3 "minefield"? At least, that's what
> the nightly trunk builds are called starting 04-11.
I was under the impression that we were planning to use "minefield" for all
trunk stuff from here on out (including Gecko 1.10 work after we ship 1.9, etc).
> "Mozilla Minefield Pre-Alpha Developer Preview 1" sounds a little scary though... ;)
Also not really expressive of what it is, if "minefield" is to be used
post-Gecko-1.9.
-Boris
Philip Chee
How about:
"Mozilla Eats Babies for Lunch Pre-Pre-Alpha Developer Preview 0.0.0.1"
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]If a program is useful, it must be changed.
* TagZilla 0.059
schiller
> trunk stuff from here on out (including Gecko 1.10 work after we ship 1.9, etc).
Makes sense, actually...
Robert O'Callahan
> I'm not sure what the thinking is about checkpointing trunk and calling
> it an alpha and what the build team costs of doing an alpha release are,
> but I can understand us not wanting to ship an alpha quite yet. At the
> same time, we've made some pretty big changes (DOM event dispatch, frame
> display lists, 2/3 of cairo) that could use testing.
>
> We probably shouldn't ship an alpha until we turn on cairo by default on
> Mac. But after that (hopefully soon?) point, what else do we need or
> want to wait for? What other large projects are scheduled for 1.9 at
> this point? I can think of reflow branch, view removal, widget removal,
> nsTextFrame rewrite, gfx removal off the top of my head. Do we want all
> those done before we ship an alpha? Or some subset of those? Are we OK
> with landing some of these after the first alpha (and do we plan to have
> multiple alpha releases)? Are there things I'm forgetting?
I think we should ship an alpha1 once we have cairo on on all platforms
and have sorted out the absolute killer issues. Hopefully we can do this
within a month?
We're going to have to ship another alpha after the reflow branch lands,
whenever that is. Hopefully that will be in time for alpha2. Probably by
then my widget changes and nsTextFrame will be in too ... this is at
least a few months away.
gfx removal is not a big issue IMHO.
Rob
Benjamin Smedberg
> We're going to have to ship another alpha after the reflow branch lands,
> whenever that is. Hopefully that will be in time for alpha2. Probably by
> then my widget changes and nsTextFrame will be in too ... this is at
> least a few months away.
At which point we should also be able to base Firefox on XULRunner. The
remaining pieces of that work are mostly gated on release engineering and
some prerequisite installer work that robstrong is doing for FF2.
--BDS
Robert O'Callahan
That will be excellent!
Rob
Chris Hofmann
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?
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=anywords&keywords =regression&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2006-03-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
About 12 or these have some kind of 1.9a1 nomination or blocker flag
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keyword s_type=anywords&keywords=regression&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2006-03-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=blocking1.9a1
One step is make sure we get fully loaded nomination and blocker list by going through the regression and other lists of bug that could be important to getting good feedback on the alpha.
68 bugs are on the blocker/nomination list right now, with many of these looking like regressions, but from longer than 6 weeks ago, and almost 1/2 owned by nobody. I'm guessing there is more work to be done to build a good list before the number starts going down.
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=anywords&keywords=regressi on&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=blocking1.9a1
A month seems optimistic to figure out any other landing plans and get a good understanding of where things stand with current trunk builds, but it might be doable if we got several people going on heavy testing, nomination and triage work
chris h.
We're going to have to ship another alpha after the reflow branch lands, whenever that is. Hopefully that will be in time for alpha2. Probably by then my widget changes and nsTextFrame will be in too ... this is at least a few months away. gfx removal is not a big issue IMHO. Rob _______________________________________________ dev-planning mailing list dev-pl...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-planning
Boris Zbarsky
> I think we should ship an alpha1 once we have cairo on on all platforms
> and have sorted out the absolute killer issues. Hopefully we can do this
> within a month?
Shipping then is what I was after, yes. I'd really like to hear from vlad, pav,
and anyone else who might know what the state of cairo on Mac is. If we can get
that on in the next two weeks and start working on the outstanding major issues,
I think doing this within a month is possible.
Note that doing all this also needs some build team support (because we really
do need to set up cairo and non-cairo perf tests across all platforms, etc). So
we're somewhat gated by our security releases here. :(
> gfx removal is not a big issue IMHO.
As I see it, it's something with a certain amount of regression likelihood as
APIs impedance-match in the move from gfx to thebes; both in terms of
performance and in terms of functionality (silly things like different arg
orders for functions that do similar things or whatnot). But I have to admit
that I haven't looked very hard at the thebes API, so maybe I'm being paranoid. ;)
-Boris
Boris Zbarsky
> There are about 77 new bugs filed with the regression keyword in the
> last 6 weeks. Many owned by nobody.
> About 12 or these have some kind of 1.9a1 nomination or blocker flag
I've been setting this on various regressions I run into...
What I think I'd really like is to be able to set the following flags today:
blocking1.9a1?
blocking1.9a2?
blocking1.9b1?
blocking1.9?
In terms of when we want to be sure that the bugs get fixed by... I know I've
been marking things that are really beta blockers in my mind as alpha blockers
just because that's all I can do with them. But maybe it's just me and we
shouldn't actually have all those flags yet and keep using the alpha bucket with
retriaging later on?
> 68 bugs are on the blocker/nomination list right now, with many of these
> looking like regressions, but from longer than 6 weeks ago
Right. Trunk's been open for 8 months, like I said...
-Boris
Robert O'Callahan
> 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
should get added to your list of "big changes". I'm not sure at this
point what the status of that is; I'll be working on the cairo-specific
issues again shortly (mainly font selection and text rendering in an
ATSUI world).
As for removing gfx, it depends on what you mean -- if you mean
removing gfx/src/gtk, windows, mac, etc., then sure, that can be done.
If you mean removing the gfx interfaces entirely, that simply won't
happen before alpha1 -- it might not even happen before Fx3 -- because
it would mean rewriting all the code that uses nsIRenderingContext
right now to do things somewhat differently. I think we're at a point
where we can start doing that, but noone's signed up for it yet (I can
do some of it, but I have some other things to finish first). I think
we may carry around the nsIRenderingContext compat layer at least
through Fx3 at this point.
- Vlad
Chris Hofmann
>
>
> 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?
>
I guess if we knew that this is what the rest of the milestone schedule
looked like we could set those up as well.
Do we agreed that that is what the backend of the milestone schedule
looks like for getting to 1.9 final? I think getting a1 and a2
milestones sorted out and triaged would tell us if we are on the path to
having the next milestone be b1 or possibly needing an a3...
> I
Peter van der Woude
> 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
> Cairo on the Mac is being blocked by Cocoa widgets on the mac, which
> should get added to your list of "big changes".
OK. So the current list of pending big changes (and their status when I
understand it) looks like:
reflow branch (status: tables being worked on, forms to be done)
view removal
widget removal
Firefox on XULRunner (status: needs release engineering and installer work)
Cocoa widgets
Cairo on the mac (status: waiting on cocoa widgets)
Coordinate system improvements (status: waiting on cairo)
nsTextFrame rewrite (status: waiting on cairo for all platforms?)
I feel like someone else mentioned something else but I'm forgetting it.... We
should probably wiki this list.
> I'm not sure at this point what the status of that is;
OK. Who would? Josh?
> As for removing gfx, it depends on what you mean -- if you mean
> removing gfx/src/gtk, windows, mac, etc., then sure, that can be done.
> If you mean removing the gfx interfaces entirely
I meant removal of the gfx interfaces yeah.
> that simply won't happen before alpha1
That was more or less what I thought, yeah.
> it might not even happen before Fx3
OK. It wasn't clear to me whether that was a "must have" for Fx3. I've removed
it from my list for the time being, since it sounds like it can happen
piecemeal instead of in a huge landing.
> (I can do some of it, but I have some other things to finish first)
Given the "waiting on" statuses above, time is probably better spent on getting
cairo on for all platforms, yeah.
Especially if roc is right and the gfx stuff can happen with relative safety (eg
in a beta cycle).
Thanks for the info!
-Boris
Boris Zbarsky
> Do we agreed that that is what the backend of the milestone schedule
> looks like for getting to 1.9 final? I think getting a1 and a2
> milestones sorted out and triaged would tell us if we are on the path to
> having the next milestone be b1 or possibly needing an a3...
That makes some sense to me.
-Boris
Mike Beltzner
I'm not sure what it means to release a trunk alpha. Is that simply a
date towards which we work to have a reasonably stable state in the
codebase? Since Firefox 3 is to be based on Gecko 1.9, is the idea
that this would be equivalent to a release of Firefox 3 Alpha 1? As
I'm often reminded, our codebase contains more than just Firefox, and
I'm assuming we'd want people to be testing the platform, not just the
Firefox product based on that platform. Also, I'm not sure that you
want to tie the trunk release schedule into the Firefox 3 product
release schedule ...
cheers,
mike
--
[ mike beltzner / user experience lead / mozilla corporation ]
Axel Hecht
My gut feeling would be that it's more important to separate a1 and b1
than a1 and a2 at the current stage, so that one can decide "well, I'd
ship an alpha with this, but not a beta". Deciding if you'd ship an
alpha2 with it seems awkward to me.
Axel
Robert O'Callahan
> As for removing gfx, it depends on what you mean -- if you mean
> removing gfx/src/gtk, windows, mac, etc., then sure, that can be done.
> If you mean removing the gfx interfaces entirely, that simply won't
> happen before alpha1 -- it might not even happen before Fx3 -- because
> it would mean rewriting all the code that uses nsIRenderingContext
> right now to do things somewhat differently. I think we're at a point
> where we can start doing that, but noone's signed up for it yet (I can
> do some of it, but I have some other things to finish first). I think
> we may carry around the nsIRenderingContext compat layer at least
> through Fx3 at this point.
Much of it is mostly-mechanical conversion. We have some good volunteers
who do that sort of thing.
Rob
Boris Zbarsky
> I'm not sure what it means to release a trunk alpha. Is that simply a
> date towards which we work to have a reasonably stable state in the
> codebase?
That's a good question. What I want is to release an alpha of Gecko 1.9. The
problem, of course, is that users don't use Gecko -- they use a browser or a
mail app or whatever. Back in the suite days, when development of front end and
back end was in sync (or rather, when there was not much front end development),
this just meant picking a time on trunk when nothing too obvious was broken,
closing the tree for a few days, making sure it passes smoketests, getting some
testing from mozillazine folks and QA for a day or two, tagging, shipping, and
reopening trunk.
At least as far as I can tell. Asa ought to be able to expand on this if you
ask him; he was a lot more involved with it than I was. ;)
> Since Firefox 3 is to be based on Gecko 1.9, is the idea
> that this would be equivalent to a release of Firefox 3 Alpha 1?
No. Firefox 3 Alpha 1 would be a release that has a good bit of the Firefox 3
UI work done too. Given that Firefox is currently working on Firefox 2, this
means that the day when that happens is a ways off.
> As I'm often reminded, our codebase contains more than just Firefox, and
> I'm assuming we'd want people to be testing the platform, not just the
> Firefox product based on that platform.
True, but testing "the platform" is hard for users without an app wrapping it
(whether that app be Firefox, Seamonkey, Epiphany, whatever).
> Also, I'm not sure that you want to tie the trunk release schedule into the Firefox 3 product
> release schedule ...
It's already tied to a certain extent -- we're not going to get the widespread
testing we need to call the trunk Gecko 1.9 done until we've done an alpha or
beta (or both!) of Firefox 3.
The goal, imo, of doing an alpha-type release of Gecko inside whatever the UI is
even though we're nowhere close to a Firefox 3 alpha is to catch various
regression issues so that when we _do_ ship the Firefox 3 alpha much later we
won't suddenly have 4 months worth of work of Gecko regression bugs filed... If
we make it clear that we want testing of the rendering engine, the group we're
interested in here (web developers) might give it a spin even without new UI stuff.
Given that trunk and 1.8 branch are keeping UI in sync with each other and that
branch UI is already considered alpha-quality, I don't foresee significant
issues in terms of UI breakage holding up whatever we decide to do on trunk, right?
-Boris
schiller
requirements on what delta SVG functionality will make it into Fx3? I
know there was a big piece outstanding for Declarative Animation/SMIL
(done by this guy:
http://brian.sol1.net/svg/2006/01/09/smil-animation-in-mozilla-report/)
but I'm not sure if this will make it for Fx3.
Is the idea something like "whatever the SVG guys can get done and
stable in time" or are there specific criteria, like "all of SVG 1.1"
:) ?
Mike Connor
> One last note. As I recall, IE7 made "releases" similar to this
> "developer preview" thing I'm suggesting -- before they ever got to beta
> they were doing random development snapshots every so often. I realize
> we do that every day, but that regularity itself means there's not as
> much "cool" factor to it as a "finally, something they've let us have a
> glimpse at" thing like IE7 snapshots. I wonder whether we could get a
> bigger testing audience with something that we not only put on the FTP
> server but also mention on some blogs, the mozilla.org web site (NOT
> mozilla.com), etc.
>
> Thoughts?
>
> -Boris
I think that we're not ready for an alpha on trunk yet, but we do need a
way to hook people into a more-stable series of builds to get wider
testing. We have a really awesome capability within software update to
drive a channel for more frequent testing, that we can update as
frequently (or as intermittently) as we want, based on need/relative
stability.
Taking into account the following:
* Human cost of doing "real" releases (QA/build/release mgmt)
* The bunching effect around extended freezes (lots of landings jammed)
* The goal being to get web developer types, not users, using these builds
* The general usefulness of being able to update more frequently than
our traditional release process allows
* The lack of current smoketesting
it seems like there's a lot of potential wins in running an update
channel for trunk.
I'd like to suggest the following process:
* Create an update channel for known-good nightlies (i.e. mozilla-unstable)
* Push these builds for the web developer/webapps community via MDC and
other outlets
* Every second Thursday, close the tree and do smoketests on
Windows/Linux/Mac nightlies
* This timeframe can be stretched or shrunk around major landings (i.e.
it might take a month to put trunk back in working order after the
reflow branch landing, or we might miss a major bug in the smoketest,
and want to push another build quickly)
* If those builds pass, push those into the mozilla-update channel (full
MARs only, since those require the least testing)
* CVS tagging/source tarballs are not done for these releases, since
they're already pulled by date, and this is a lot of overhead.
* No UA/versioning/branding changes should be necessary, these are not
releases, they're just better-tested/theoretically safer builds
This should, positioned correctly, get us more trunk testers with less
effort, since the effort involved in keeping up is minimized, the
smoketested builds would mean a lot less pain for people in that
channel, and because of the vastly diminished overhead, we can fit
updates to the pace of development, instead of the other way around.
-- Mike
Axel Hecht
> Boris Zbarsky wrote:
<...>
> * Create an update channel for known-good nightlies (i.e. mozilla-unstable)
> * Push these builds for the web developer/webapps community via MDC and
> other outlets
> * Every second Thursday, close the tree and do smoketests on
> Windows/Linux/Mac nightlies
Every other week is a timeframe that is terribly hard to organize. I'd
expect that someone checks into the closed tree each and every time, and
closing the tree for one day every 14 sounds a bit intrusive to me.
I'd rather go for first whatever of the month.
> * This timeframe can be stretched or shrunk around major landings (i.e.
> it might take a month to put trunk back in working order after the
> reflow branch landing, or we might miss a major bug in the smoketest,
> and want to push another build quickly)
> * If those builds pass, push those into the mozilla-update channel (full
> MARs only, since those require the least testing)
> * CVS tagging/source tarballs are not done for these releases, since
> they're already pulled by date, and this is a lot of overhead.
> * No UA/versioning/branding changes should be necessary, these are not
> releases, they're just better-tested/theoretically safer builds
>
> This should, positioned correctly, get us more trunk testers with less
> effort, since the effort involved in keeping up is minimized, the
> smoketested builds would mean a lot less pain for people in that
> channel, and because of the vastly diminished overhead, we can fit
> updates to the pace of development, instead of the other way around.
Whichever timeframe we end up with, we should coordinate that with the
availability of builds to hunt down regression windows.
Axel
Robert Kaiser
> Vladimir Vukicevic wrote:
>> Cairo on the Mac is being blocked by Cocoa widgets on the mac, which
>> should get added to your list of "big changes".
>
> OK. So the current list of pending big changes (and their status when I
> understand it) looks like:
>
> reflow branch (status: tables being worked on, forms to be done)
> view removal
> widget removal
> Firefox on XULRunner (status: needs release engineering and installer work)
> Cocoa widgets
> Cairo on the mac (status: waiting on cocoa widgets)
> Coordinate system improvements (status: waiting on cairo)
> nsTextFrame rewrite (status: waiting on cairo for all platforms?)
>
> I feel like someone else mentioned something else but I'm forgetting
> it.... We should probably wiki this list.
Good idea.
I think though that there should be a separation of platform and
application changes ("Firefox on XULRunner" is basically an
application-only change, I guess, while the rest of the list are
platform changes).
Just for those who are interested, we also have application-specific
"big changes" on our list for SeaMonkey, which would be as follows:
consolidation of SeaMonkey-specific code in suite/
"source L10n" (support of cvs-based localization)
migration from xpfe to toolkit (with XULRunner as long-term target)
Status for all those is "started, but still in the early stages".
Robert Kaiser
Benjamin Smedberg
> I'm assuming we'd want people to be testing the platform, not just the
> Firefox product based on that platform. Also, I'm not sure that you
> want to tie the trunk release schedule into the Firefox 3 product
> release schedule ...
I'm not sure I understand the distinction in this case. People should
*always* be "testing the platform, not just the Firefox product based on the
platform". Even for Firefox 2 there is a decent chance that safe-looking
changes in the backend or frontend code could affect the web platform, not
just the user experience.
The trunk release schedule is intimately tied up with the Firefox 3 product
schedule of necessity: it's impossible to consider doing a "platform"
release without full and integrated testing of the primary platform consumer
(Firefox). All of the trunk work is targeted at a Firefox 3 release in Q1
2007. We need to start widespread testing of underlying changes now-ish in
order to have any chance of hitting that goal.
We may not want to call it a "Firefox 3 alpha" since the frontend is largely
the same as the Firefox 2 alphas. Basically what we need to release are
"bonecho alpha frontend with gecko 1.9a backend" bits, with at least a
little expectation of stability in both pieces. In my ideal world this would
happen at about the time of bonecho alpha-2 (mid-May). Call those bits what
you will to avoid confusion.
--BDS
Mike Connor
> Mike Connor wrote:
>> Boris Zbarsky wrote:
>
> <...>
>
>> * Create an update channel for known-good nightlies (i.e.
>> mozilla-unstable)
>> * Push these builds for the web developer/webapps community via MDC
>> and other outlets
>> * Every second Thursday, close the tree and do smoketests on
>> Windows/Linux/Mac nightlies
>
> Every other week is a timeframe that is terribly hard to organize. I'd
> expect that someone checks into the closed tree each and every time, and
> closing the tree for one day every 14 sounds a bit intrusive to me.
What organization is needed? We close the tree for half a day to
smoketest stuff (which is basically three MozQA people for a few hours),
if things pass, we reopen the tree and dump those builds in the update
channel (preed or rhelmer can probably do this easily by now, especially
for only three builds).
The point is to spend less time frozen than we will if we're doing
bigger increments. We used to close the tree like this five days a
week, so what makes doing it once every two weeks so intrusive?
> I'd rather go for first whatever of the month.
Its easier, sure, but it means larger changesets and larger potential
regression windows to find regressions. It also would lead to more
bunching around freezes (needs testing, can't wait another month, etc),
which I'd like to avoid. The point is to catch things as soon as
possible and to make checkpoints frequent enough that there isn't a big
rush to hit any particular one.
Once we get into betas I think that's entirely possible that we could
bump up to once a week, since at that stage we should be able to
consistently ship stable builds.
> Whichever timeframe we end up with, we should coordinate that with the
> availability of builds to hunt down regression windows.
We'll still have these builds on the ftp somewhere for archiving/linking
from announcements (i.e. we would have a Gecko Team blog that we
announce these builds on, so people know what especially needs testing).
-- Mike
Mike Beltzner
> The trunk release schedule is intimately tied up with the Firefox 3
> product schedule of necessity: it's impossible to consider doing a
> "platform" release without full and integrated testing of the primary
> platform consumer (Firefox). All of the trunk work is targeted at a
> Firefox 3 release in Q1 2007. We need to start widespread testing of
> underlying changes now-ish in order to have any chance of hitting that
> goal.
I guess I'm confused because I haven't really seen any firm plans
about the roadmap for Gecko 1.9, so this desire to "release" something
really looks more like a "we've been doing lots of stuff, and we want
people to poke at it" than a targeted or managed release.
While Firefox 3 is obviously a primary consumer of the platform, I
don't think we should tightly couple the release schedules. I think
the Gecko release should treat Firefox 3 as a consumer, and get
requirements in terms of scheduling and functionality just like it
would from any other consumer (such as XULRunner or Thunderbird) and
then triage and schedule appropriately. I'm not saying that it needs
to be confrontational or that the two things should work as if neither
exists, but we probably shouldn't just assume that "gecko 1.9 will be
done when Firefox 3 is released."
> the same as the Firefox 2 alphas. Basically what we need to release are
> "bonecho alpha frontend with gecko 1.9a backend" bits, with at least a
> little expectation of stability in both pieces. In my ideal world this
Exactly. I think what we're looking to release is a stable snapshot of
the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
site with all of the various applications (Fx, Tb, Sb?, XR?) that are
built off that codebase.
I want to avoid calling this a "3.0 Alpha" since those alphas should
be managed and scheduled by the groups that are focused on defining
what those v3 products will look like.
I know that I'm sort of splitting hairs here, but as we decouple the
product and platform development cycle, I think this sort of
differentiation is needed.
Boris Zbarsky
> I guess I'm confused because I haven't really seen any firm plans
> about the roadmap for Gecko 1.9
Other than the feature list, I assume?
> so this desire to "release" something
> really looks more like a "we've been doing lots of stuff, and we want
> people to poke at it" than a targeted or managed release.
That's correct. That's exactly what I want, at least. I'm not interested in
user-facing anything here; I just want feedback on which web sites and intranet
apps we've broken so we can fix them now, and not during the release crunch.
> Exactly. I think what we're looking to release is a stable snapshot of
> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
> built off that codebase.
Yep. And trumpet said snapshot a bit.
> I want to avoid calling this a "3.0 Alpha"
Agreed.
-Boris
Boris Zbarsky
> While Firefox 3 is obviously a primary consumer of the platform, I
> don't think we should tightly couple the release schedules. I think
> the Gecko release should treat Firefox 3 as a consumer, and get
> requirements in terms of scheduling and functionality just like it
> would from any other consumer (such as XULRunner or Thunderbird) and
> then triage and schedule appropriately.
I should note that that's filed twice already -- with Gecko 1.7 and Gecko 1.8.
The only way this can really work is if there is communication about
infrastructure changes needed by Firefox while Gecko is in an alpha cycle (or
before, e.g. if Firefox runs into issues with a given Gecko version, file bugs
so they will be fixed in the next one).
There's been a bit more of that this time around (at least in terms of Firefox
2; I have no idea what the state of Firefox 3 is), so maybe it'll all work out
this time.
Also, should we really be talking about the Gecko development cycle? Or the
XULRunner development cycle?
> but we probably shouldn't just assume that "gecko 1.9 will be
> done when Firefox 3 is released."
Sure, but at the same time we know Gecko 1.9 will not be done until at least a
beta of Firefox 3 is released -- we need the widespread testing that will provide.
-Boris
Chris Hofmann
> 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 build long enough to provide good, in-depth, usage and feedback the
user facing parts need to be in good enough shape that they will use the
app for their daily work and extended periods of time. So finding and
fixing up any critical user facing problems is key to getting some
testing and feedback on websites and intranet apps.
>
>> Exactly. I think what we're looking to release is a stable snapshot of
>> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
>> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
>> built off that codebase.
>
> Yep. And trumpet said snapshot a bit.
Its going to be tough to get any widespread testing of trunk snapshot
builds named "minefield"... I think that code name, or
characterization, or branding for trunk builds is the wrong direction to
be heading in. We should be continuing to encourage and create a large
development and testing community of 10,000 to 20,000 or more to help
out in keeping the trunk as stable as possible at all times. We should
be and keeping destabilizing changes away from the trunk until they are
baked and ready to land. minefield sends the wrong message if these are
still our goals. This becomes harder the more branches we are working
on in parallel, but I still think it is a goal.
>
>> I want to avoid calling this a "3.0 Alpha"
>
> Agreed.
>
> -Boris
Benjamin Smedberg
> I guess I'm confused because I haven't really seen any firm plans
> about the roadmap for Gecko 1.9, so this desire to "release" something
> really looks more like a "we've been doing lots of stuff, and we want
> people to poke at it" than a targeted or managed release.
Perhaps I (we) don't understand what you mean by a targeted or managed
release. We had a set of goals to accomplish for "the platform", including
the reflow branch, cairo graphics, xulrunner, whatnot... we need to have
releases at various checkpoints to collect feedback/regression/performance data.
> While Firefox 3 is obviously a primary consumer of the platform, I
> don't think we should tightly couple the release schedules. I think
On the contrary, I think we absolutely *must* tightly couple the release
schedules: it is impossible to release "the platform" without thorough
testing coverage, and the only sane way to get thorough test coverage is
through Firefox releases.
> the Gecko release should treat Firefox 3 as a consumer, and get
> requirements in terms of scheduling and functionality just like it
> would from any other consumer (such as XULRunner or Thunderbird) and
If we're splitting hairs, these are very different examples. XULRunner is at
its least a build artifact of "the platform", and at most a full
productization of the platform. Thunderbird is a client app.
> exists, but we probably shouldn't just assume that "gecko 1.9 will be
> done when Firefox 3 is released."
How would you do otherwise. There is absolutely no point in releasing gecko
1.9 before Firefox 3 is finished (because the QA and testing of the platform
happens in Firefox release cycles); and it's obviously not possible to say
that gecko 1.9 could be done after FF3.
> I know that I'm sort of splitting hairs here, but as we decouple the
> product and platform development cycle, I think this sort of
> differentiation is needed.
I do not think that we have "decoupled" these cycles at all. We have put two
product cycles into a platform cycle, and made some guarantees about
platform stability between those two releases (for the benefit of the web
and the low-level extension ecosystem, primarily). That's not the same thing
at all as a decoupled schedule.
--BDS
L. David Baron
> I guess I'm confused because I haven't really seen any firm plans
> about the roadmap for Gecko 1.9, so this desire to "release" something
> really looks more like a "we've been doing lots of stuff, and we want
> people to poke at it" than a targeted or managed release.
I don't see why you think releases have to be built that way.
There are too many people working on different areas of Gecko to
coordinate in that way. The different areas (in which developers can
swtich from one piece of code to another) often do have more detailed
plans -- in terms of what is higher and lower priority. Then once
there's a targeted release date they know what's unsafe to do in time to
be stable for the release. But there's no reason that the people
working on layout, DOM, or networking have to agree in advance which of
their features will make it in -- then incorrect time estimates could
easily lead to one of those groups being ready for the release 6 months
before another. This is exactly the problem that's caused huge amounts
of tension around recent Firefox releases.
But that doesn't mean these changes don't need testing in alpha form.
> > the same as the Firefox 2 alphas. Basically what we need to release are
> > "bonecho alpha frontend with gecko 1.9a backend" bits, with at least a
> > little expectation of stability in both pieces. In my ideal world this
>
> Exactly. I think what we're looking to release is a stable snapshot of
> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
> built off that codebase.
I don't think this makes sense. The vast majority of the changes that
need widespread testing are changes that affect how we display Web
pages. Thus the key here is releasing a Web browser. Releasing
everything else would just make shipping an alpha harder, when it can
really be something that's really easy to do, relative to most of the
other things the build team does.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
L. David Baron
> Its going to be tough to get any widespread testing of trunk snapshot
> builds named "minefield"... I think that code name, or
> characterization, or branding for trunk builds is the wrong direction to
> be heading in. We should be continuing to encourage and create a large
> development and testing community of 10,000 to 20,000 or more to help
> out in keeping the trunk as stable as possible at all times. We should
> be and keeping destabilizing changes away from the trunk until they are
> baked and ready to land. minefield sends the wrong message if these are
> still our goals. This becomes harder the more branches we are working
> on in parallel, but I still think it is a goal.
Agreed.
And what's pissed me off about our release process ever since Firefox
became the flagship app is that the Firefox leads have insisted on
controlling the Firefox release process as if it weren't also the
primary testing and release vehicle for Gecko.
This is why, following Firefox 1.0, I sat down with Ben and many others
to develop a plan that would allow Firefox to really become the flagship
Gecko app:
http://groups.google.com/group/netscape.public.mozilla.seamonkey/msg/0883b9b35d3400af
Part of this Firefox 1.1 (later 1.5) plan involved shipping a
Firefox-based Gecko alpha in early January of 2005. The agreement by
the Firefox leads to that 1.1 plan was the only reason I accepted
dropping the suite as the flagship Gecko app.
That plan was nowhere close to being met, and it now seems like the
current Firefox leads aren't even willing to accept its rationale --
that Gecko needs to ship reasonably frequent Web browser alphas to tens
or hundreds of thousands of users so that regressions in handling of Web
pages are found. This requires more users than most other types of
testing-by-alpha because most Web pages are used by only a tiny portion
of Web users.
If Firefox leads aren't comfortable with what being the flagship Gecko
app means, then I think we need to restore the Mozilla Suite to that
role -- not because I like the suite, but because we need a Web browser
that we can release to get Gecko testing.
Robert Kaiser
> I don't think this makes sense. The vast majority of the changes that
> need widespread testing are changes that affect how we display Web
> pages. Thus the key here is releasing a Web browser. Releasing
> everything else would just make shipping an alpha harder, when it can
> really be something that's really easy to do, relative to most of the
> other things the build team does.
This should be Gecko test releases, right?
So why not just release a Firefox snapshot officially branded as "Gecko
Browser Preview 2006-06-24" or something like that?
The "Gecko Browser" name has been used previously for nightlies already,
and it would make clear what it's about, additionally give the "Gecko"
brand some publicity among testers and web developers.
I think though that actually providing XULRunner binaries along with
those alpha snapshots might be a good idea, so that other (possibly
external) platform users have their target for testing with newer
versions. And as Firefox (or "Gecko Browser" for that matter) should
only be an additional layer on top of a "vanilla" XULRunner, it should
probably be easy to do both packages in one run.
Robert Kaiser
Mike Beltzner
> >> 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 build long enough to provide good, in-depth, usage and feedback the
> user facing parts need to be in good enough shape that they will use the
> app for their daily work and extended periods of time. So finding and
> fixing up any critical user facing problems is key to getting some
> testing and feedback on websites and intranet apps.
Well, we're still landing all the new front end features on both the
1.8-branch and the trunk, right? So if we target this trunk release to
be coincident with a 1.8-branch release, then we shouldn't need to
worry about the user-facing parts not being good enough.
I think the issue we need to worry about is splitting our testing
community: should they be testing the browser using trunk or branch? I
can see arguments for both, really. For instance, in the short term,
the success of Firefox 2 depends on getting a lot of eyes testing
those user-facing features without having them distracted by the
platform related regressions or bustages. In the long term, as both
you and dbaron mention, we need eyes on the platform related stuff.
> >> Exactly. I think what we're looking to release is a stable snapshot of
> >> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
> >> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
> >> built off that codebase.
> >
> > Yep. And trumpet said snapshot a bit.
> Its going to be tough to get any widespread testing of trunk snapshot
> builds named "minefield"... I think that code name, or
I call "straw man". Nobody ever suggested that a published "release"
should be called Minefield. That name, as mentioned over and over
again in bug 308973, is intended to be used as the default branding
for apps built right off the trunk specifically to warn people that
there's no guarantee of stability. If we were to take a snapshot that
was known to be stable, we'd presumably give it a different name.
> characterization, or branding for trunk builds is the wrong direction to
> be heading in. We should be continuing to encourage and create a large
> development and testing community of 10,000 to 20,000 or more to help
> out in keeping the trunk as stable as possible at all times. We should
Out of curiousity, how many people are running trunk nightlies? What's
the delta we're looking to attract here?
Mike Connor
> Boris Zbarsky 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 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.
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.
> builds named "minefield"... I think that code name, or
> 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.
> 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.
development are not going to be scared off by the fact that its called
Minefield. Especially right now, nightlies, even more stable ones, are
going to be somewhat unpredictable, and may have grandma killing bugs we
haven't found out about. We've absolutely done that in the past, and
will continue to do that in the future, so full disclosure even in
naming shouldn't be a problem. If users are willing to be real dogfood
users, then the name shouldn't be a problem. That said, doing more
parallel work would be nice, but we've optimized away from that in the
last couple of years, maybe we need to rethink that.
Based on some handwavy stats from AUS, we currently have around 6000
people using nightlies every day. There were 12k unique users of
nightlies in the first half of March, so that really seems like we're
already mostly there. Do we need more? More is always better, but only
if those additional users are going to file good bugs and help out in
that kind of way. Quality, not quantity, of testing is the benchmark we
need to focus on, IMO.
-- Mike
Boris Zbarsky
> I think the issue we need to worry about is splitting our testing
> community: should they be testing the browser using trunk or branch?
Some of both, unfortunately. I thought part of the point of keeping the UI in
sync was that trunk testing happening right now would still benefit Firefox 2,
so we could try to move testing resources to trunk as needed.
> In the long term, as both
> you and dbaron mention, we need eyes on the platform related stuff.
That long term is now, imo. Again, it's been 8 months since we branched... How
much longer term could we really get? ;)
Back to scheduling, if we _can_ do the trunk release at about the same time as a
branch release then you're probably right that the UI should be fairly
non-busted. So what does the branch release schedule look like?
-Boris
Jonas Sicking
There are a few things that I think are important.
First of all I'm worried about confusion if we release a FF 3 alpha
before FF 2 is out the door. However, this problem would be lessened a
lot, or even go away, if we name the release something other then
"Firefox 3 alpha".
Second, I think we need to make sure we get the right people to download
and test this thing. We have had a problem in the past with people not
testing heavily until it's too late to actually fix bad regressions.
Unfortunately I don't really have a good answer to this one, other than
possibly saying "don't spend time on too many alphas that don't get
heavy testing anyway". Really, do we get a lot of people testing alphas
that aren't already testing nightlies?
Lastly, I think deciding on an aimed release date is the first thing we
should do since without that anything we do is likely too early or too
late. We probably don't need to hammer out an exact date, but within a
month or two seems reasonable.
/ Jonas
Mike Beltzner
>
> > 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
> On Wednesday 2006-04-12 13:10 -0700, Chris Hofmann wrote:
> > builds named "minefield"... I think that code name, or
> > 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.
>
>
> And what's pissed me off about our release process ever since Firefox
> became the flagship app is that the Firefox leads have insisted on
> controlling the Firefox release process as if it weren't also the
> primary testing and release vehicle for Gecko.
>
> This is why, following Firefox 1.0, I sat down with Ben and many others
> to develop a plan that would allow Firefox to really become the flagship
> Gecko app:
> http://groups.google.com/group/netscape.public.mozilla.seamonkey/msg/0883b9b35d3400af
> Part of this Firefox 1.1 (later 1.5) plan involved shipping a
> Firefox-based Gecko alpha in early January of 2005. The agreement by
> the Firefox leads to that 1.1 plan was the only reason I accepted
> dropping the suite as the flagship Gecko app.
>
> That plan was nowhere close to being met, and it now seems like the
> current Firefox leads aren't even willing to accept its rationale --
> that Gecko needs to ship reasonably frequent Web browser alphas to tens
> or hundreds of thousands of users so that regressions in handling of Web
> pages are found. This requires more users than most other types of
> testing-by-alpha because most Web pages are used by only a tiny portion
> of Web users.
So we get tens of thousands of people testing trunk builds. And then
we get hundreds of thousands of more casual users testing product
alphas and betas. And when the product releases start building off of
trunk, the number of testers on trunk jumps up nicely to coincide with
the point in time where trunk code is ready to expand to a wider
testing audience.
Win-win, isn't it?
> If Firefox leads aren't comfortable with what being the flagship Gecko
> app means, then I think we need to restore the Mozilla Suite to that
> role -- not because I like the suite, but because we need a Web browser
> that we can release to get Gecko testing.
What do you mean when you say "release"? What's involved there in
terms of engineering, publicity and socialization?
Mike Beltzner
> Mike Beltzner wrote:
> > I think the issue we need to worry about is splitting our testing
> > community: should they be testing the browser using trunk or branch?
>
> Some of both, unfortunately. I thought part of the point of keeping the
> UI in sync was that trunk testing happening right now would still benefit
> Firefox 2, so we could try to move testing resources to trunk as needed.
I think it was mostly to reduce the pain of merging back to trunk from
a branch, as was experienced with aviary->gecko 1.8. That was the
rumour I heard or read off a bathroom wall or something, anyway ;)
> > In the long term, as both
> > you and dbaron mention, we need eyes on the platform related stuff.
>
> That long term is now, imo. Again, it's been 8 months since we
> branched... How much longer term could we really get? ;)
You don't actually want an answer to that question, do you?
> Back to scheduling, if we _can_ do the trunk release at about the same
> time as a branch release then you're probably right that the UI should be
> fairly non-busted. So what does the branch release schedule look like?
We're targetting Bon Echo Alpha 2 at May 9th at the moment, with code
freeze on May 5th. There's a rough schedule for B1, B2 and the RCs at
http://wiki.mozilla.org/Firefox2/Schedule
cheers,
mike
Boris Zbarsky
> I mean that I don't know where the set of things that are going into
> trunk is being catalogued
http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan has some info, but I
agree that this list is not being maintained. I'll try to set up a wiki page
with the list I have compiled so far and whatever "owner", status, and date info
I can come up with... That's just in terms of the code.
> nor do I know where I can get a sense of what the targets are for alphas, betas, and release candidates for the
> trunk. Nor, really, do I know how those releases will be expressed,
> but that seems to be precisely what we're talking about atm :)
Right.
> So I'm confused about the goal: do we want to publish an alpha
> release, where we set firm goals about what will or won't be in that
> release, and scope priorities in terms of moving the trunk from one
> milestone to the next, or do we want to simply ensure that there's a
> stable state for the trunk
I don't think we can do the latter without doing the former for trunk work.
Otherwise we'll just have big landings happening just about as we stabilize from
the previous landing. So yes, I think we need to ensure a stable state for the
trunk and to that end we need firm goals about what will be in that stable state
(and what won't be, probably). Getting this defined was one of the things I
wanted to come out of this thread.
> I think we all agree
> that calling it "Firefox 3 Alpha" isn't the right thing to do, since
> that's gonna get misinterpreted by the general public.
Well, it's not clear that everyone agreed, but I'm personally ok with calling it
something else (I stand by my "Firefox 3 Developer Preview" suggestion). Unless
your problem is with the "3" in there?
-Boris
L. David Baron
> > That plan was nowhere close to being met, and it now seems like the
> > current Firefox leads aren't even willing to accept its rationale --
> > that Gecko needs to ship reasonably frequent Web browser alphas to tens
> > or hundreds of thousands of users so that regressions in handling of Web
> > pages are found. This requires more users than most other types of
> > testing-by-alpha because most Web pages are used by only a tiny portion
> > of Web users.
>
> So we get tens of thousands of people testing trunk builds. And then
Whatever the number we have testing trunk builds, it isn't enough. (And
it sounds like it might be ten thousand, but not tens of thousands.) We
got too many very-old regressions filed once Firefox 1.5 started
shipping alphas and betas, and it's probably going to happen again (and
perhaps even worse) for 3.0, at the rate we're going.
Regression bug reports are much more useful when the code is still fresh
in its authors' mind, and when there's enough time to fix them before
the release.
> we get hundreds of thousands of more casual users testing product
> alphas and betas.
Not at any reasonable interval.
> And when the product releases start building off of
> trunk, the number of testers on trunk jumps up nicely to coincide with
> the point in time where trunk code is ready to expand to a wider
> testing audience.
We need it to hit a wider testing audience more often than we do now.
And I don't see why you think the trunk Gecko code becomes more ready to
expand to a wider testing audience when Firefox has met its
product-planned goals.
> Win-win, isn't it?
No, and I think you already knew I thought not.
Mike Beltzner
> On Thursday 2006-04-13 01:01 -0400, Mike Beltzner wrote:
> > > That plan was nowhere close to being met, and it now seems like the
> > > current Firefox leads aren't even willing to accept its rationale --
> > > that Gecko needs to ship reasonably frequent Web browser alphas to tens
> > > or hundreds of thousands of users so that regressions in handling of Web
> > > pages are found. This requires more users than most other types of
> > > testing-by-alpha because most Web pages are used by only a tiny portion
> > > of Web users.
> >
> > So we get tens of thousands of people testing trunk builds. And then
>
> Whatever the number we have testing trunk builds, it isn't enough. (And
> it sounds like it might be ten thousand, but not tens of thousands.) We
> got too many very-old regressions filed once Firefox 1.5 started
> shipping alphas and betas, and it's probably going to happen again (and
> perhaps even worse) for 3.0, at the rate we're going.
> Regression bug reports are much more useful when the code is still fresh
> in its authors' mind, and when there's enough time to fix them before
> the release.
You're coming up with a lot of great points for why we need more
testing on trunk, and I'm sold on the idea, but I don't see any
counter-proposals to the solutions that I'm putting forward. Are you
proposing that we do frequent releases of Firefox off the trunk? What
would constitute such a release? Why do you expect that doing so would
get more people using that version for their web browsing?
The way I see it, there are a couple of options:
1. Firefox 2 releases as planned. Simultaneously, stabilize trunk such
that a set of solid builds can be made at some regular interval (let's
say monthly?) and then call those builds "latest-stable-trunk" or
something and socialize the need for testing and how these builds are
good enough for day to day use.
2. Firefox 2 releases as planned. Quickly build out a set of milestone
dates for Firefox 3 (with several alphas) and start releasing those as
well, perhaps initially synchronized to the Firefox 2 release
schedule. Or maybe it would be better to stagger the releases such
that our testers could use one for a month, then another for a month,
etc.
3. Make Firefox 3 releases the "flagship" alphas which we ask people
to use, since any front-end bugs will be discovered from here, too.
When the front-end stuff reaches beta level, then continue publishing
alphas from trunk, but also release Firefox 2 betas based on the 1.8
branch.
> > we get hundreds of thousands of more casual users testing product
> > alphas and betas.
>
> Not at any reasonable interval.
>
> > And when the product releases start building off of
> > trunk, the number of testers on trunk jumps up nicely to coincide with
> > the point in time where trunk code is ready to expand to a wider
> > testing audience.
>
> We need it to hit a wider testing audience more often than we do now.
Just "releasing" something doesn't guarantee a wider test audience.
Were I not in the know, I'd have no idea if I should be using Firefox
2 or Firefox 3. Also, I want people paying attention and submitting
bugs on the front end changes as well; you seem to be implying that
these code changes are less risky/worth testing than trunk changes.
> And I don't see why you think the trunk Gecko code becomes more ready to
> expand to a wider testing audience when Firefox has met its
> product-planned goals.
Didn't mean to imply that, sorry, my bad. What I meant to imply was
that if we assume that the number of testers is a finite resource, and
if we have to prioritize where their attention should go, then I would
suggest that we try to focus that resource more on our n+1 product
than on our n+2 initially, and then shift it as we get close to
releasing n+1.
> > Win-win, isn't it?
>
> No, and I think you already knew I thought not.
Believe it or not, I was actually hoping that we might have been
moving towards some sort of constructive solution. Apparently I'm
still new enough to have that kind of optimism.
L. David Baron
> The way I see it, there are a couple of options:
>
> 1. Firefox 2 releases as planned. Simultaneously, stabilize trunk such
> that a set of solid builds can be made at some regular interval (let's
> say monthly?) and then call those builds "latest-stable-trunk" or
> something and socialize the need for testing and how these builds are
> good enough for day to day use.
>
> 2. Firefox 2 releases as planned. Quickly build out a set of milestone
> dates for Firefox 3 (with several alphas) and start releasing those as
> well, perhaps initially synchronized to the Firefox 2 release
> schedule. Or maybe it would be better to stagger the releases such
> that our testers could use one for a month, then another for a month,
> etc.
>
> 3. Make Firefox 3 releases the "flagship" alphas which we ask people
> to use, since any front-end bugs will be discovered from here, too.
> When the front-end stuff reaches beta level, then continue publishing
> alphas from trunk, but also release Firefox 2 betas based on the 1.8
> branch.
I'm happy with any of these, at least assuming (1) would be done in a
prominent enough way that it gets users. I expect others would be
unhappy with (3), and I wasn't pushing for it.
> > > Win-win, isn't it?
> >
> > No, and I think you already knew I thought not.
>
> Believe it or not, I was actually hoping that we might have been
> moving towards some sort of constructive solution. Apparently I'm
> still new enough to have that kind of optimism.
Then I must have misread your message: when you wrote "we get", I
thought you were describing the present situation, but I think you
actually were describing the result of the proposed changes (for which I
would have used "we would get").
Robert Kaiser
> What I'm getting at is that I feel like we need to
> shift our way of thinking about things so that people developing the
> trunk aren't forced to do so *only* in service of Firefox. So the
> platform is considered to be its own product, and apps built off of it
> like Firefox will pick stable-ish points from which to cut branches
> that will become the base of their releases. This nets out to mostly a
> semantic difference, I guess.
In a world where apps are all created on top of identical XULRunner
builds (and I think we agree that this should be the future for all of
us), the model we are working towards works fine, basically as you
described:
The platform (under the name of XULRunner) gets branched for a stable
release at some point, and apps do their stabilizing on the same branch
possibly (touching only their app-specific directory, i.e. browser/,
mail/, suite/, composer/, etc.) and are able to release off a point
that's declared "stable" by XULRunner developers.
Of course, they can always release at a later point using the same
stable XULRunner state/release, e.g. by doing a minibranch (client.mk +
their app-specific dir) off the release tag/minibranch/branch.
Releasing platform/XULRunner alphas (directly off trunk, probably
without the effort of branching) in between should be very much
scheduled (monthly, date-versioned?), so that any apps that want to
release own pre-releases from such a stable-ish point can either try to
stabilize at the same point or do their own minibranch based on that
platform alpha tree. For sure, the projects should know when they can
schedule for themselves to get to such a point (give or take a few days,
of course).
Still, the platform/XULRunner alphas need some "tesing instrument" which
is a showcase for the platform, and esp. for Gecko, so releasing a
"Gecko Browser" (i.e. Firefox) xulapp along with it would be a good idea.
At least, that sounds good for the glorious future where XULRunner is a
well-defined common base for all our apps. In the mean time, where we
still have no single app that's fully XULRunner-based and ready for a
preview-release, we can work towards such a sheme though, and use all
elements of it that do already fit.
Jugding from how we are/were dealing with releases off the 1.8.0 branch
(esp. Firefox/Thunderbird and SeaMonkey), we are not quite as far from
that model as one might think - though it needs much more coodination
with affected groups as it probably will in the fully XULRunner-based
world (though coordination and communication between projects and
platform is always a good idea).
Robert Kaiser
Jonas Sicking
you)
The primary reason we're releasing alphas and betas is that we want
people to test stuff with it. Like we want web-developers to test that
their site works, and we want extension-developers to test that their
extensions still work.
However, a lot of people are vary of installing an alpha version that
might wreck their bookmarks, eat their preferences and stomp on their
cookies.
So I wonder if it might make sense to create a distro that is more
sandboxed and is less likely to screw up their day-to-day firefox install.
In fact, there already is such a distro: Portable firefox.
If we could put portable versions of our releases right visible on the
alpha page and in the alpha announcements, people might be more willing
to give it a go.
We could even make portable firefox to optionally import the config
files of an existing install.
What do people think? Is it worth the effort? Maybe this is more
important to the later alphas?
/ Jonas
Jonas Sicking
> Mike Beltzner wrote:
>> I think the issue we need to worry about is splitting our testing
>> community: should they be testing the browser using trunk or branch?
>
> Some of both, unfortunately. I thought part of the point of keeping the
> UI in sync was that trunk testing happening right now would still
> benefit Firefox 2, so we could try to move testing resources to trunk as
> needed.
I'm not sure that there is a huge advantage in shipping an alpha now, as
opposed to shipping one a bit after FF2 is out the door. Regressions are
generally not too hard to fix, it is finding them that is the problem.
So it might not be too bad to live with a regression a bit longer on the
trunk and make sure that we get a lot of testing at some point well
before we're approaching any sort of freeze.
So I think a well trumpeted, well tested alpha a bit down the road is
better then a half-trumpeted and half-tested now, and another
half-trumpeted and half-tested a bit later. In other words, I think it's
better to get more people testing, then to get the same people to test
multiple times.
I think (someone correct me if i'm overly optimistic) that we're keeping
good enough quality through the nightly releases that we don't have a
lot of test-blocking level bugs.
/ Jonas
fantasai
> Slightly selfish, er, tangential question here: Are there any
> requirements on what delta SVG functionality will make it into Fx3? I
> know there was a big piece outstanding for Declarative Animation/SMIL
> (done by this guy:
> http://brian.sol1.net/svg/2006/01/09/smil-animation-in-mozilla-report/)
> but I'm not sure if this will make it for Fx3.
>
> Is the idea something like "whatever the SVG guys can get done and
> stable in time" or are there specific criteria, like "all of SVG 1.1"
> :) ?
I can't imagine a day when "all of SVG 1.1" will be on the requirements list.
~fantasai
Boris Zbarsky
> I'm not sure that there is a huge advantage in shipping an alpha now, as
> opposed to shipping one a bit after FF2 is out the door. Regressions are
> generally not too hard to fix, it is finding them that is the problem.
This is not my experience with changes to architecture. Often, fixing
regressions requires further architecture changes...
> So it might not be too bad to live with a regression a bit longer on the
> trunk and make sure that we get a lot of testing at some point well
> before we're approaching any sort of freeze.
The problem is that if at that point we have a number of regressions that make
the builds not testable by the general public then we have to do multiple alpha
cycles as the regressions are discovered. If we start having alphas later,
we'll have fewer alpha cycles, which will, imo, mean fewer regressions found.
> So I think a well trumpeted, well tested alpha a bit down the road is
> better then a half-trumpeted and half-tested now, and another
> half-trumpeted and half-tested a bit later.
I'm not sure I buy that, but in any case it's worse than a half-trumpeted one
now and a well-trumpeted one later. I'm not proposing we skip on later alphas
just because we do one sooner.
> I think (someone correct me if i'm overly optimistic) that we're keeping
> good enough quality through the nightly releases that we don't have a
> lot of test-blocking level bugs.
I think you're being overly optimistic. As a simple example, I'm currently
using a February nightly for most of my browsing; there have been regressions
almost constantly in various functionality areas since then, and the switch to
Cairo makes our nightlies unusably slow on my computer (3-4 seconds to repaint
the window after I do any window manager operation; 1-2 seconds to repaint when
the window loses or gains focus).
So the current trunk quality is certainly blocking testing by me, as far as that
goes.
-Boris
fantasai
Issues:
- *Gecko trunk needs more testing, especially by web-developer types*
-> Need a browser front end, other apps not as important for this
(Boris writes: I just want feedback on which web sites and
intranet apps we've broken so we can fix them now, and not
during the release crunch.)
- *Want to catch regressions in Gecko earlier in the release cycle*
- *There are some major Gecko changes just in / going in* within the
next month or two that need widespread QA exposure.
-> bz is compiling a list of these
- Trunk firefox code is synced with FF2 branch
-> Using its front end will be a useful QA windfall for FF team,
even though that's not the focus here
- Triage could use more blocking nomination flags for Gecko
-> Should have flags for at least one alpha and one beta release
(Axel writes: It's more important to separate a1 and b1 than a1
and a2 at the current stage, so that one can decide "well, I'd
ship an alpha with this, but not a beta".)
Release Planning Ideas:
- Release a rebranded Firefox as the Gecko testing vehicle
-> Nightlies are branded as "Minefield".
-> Proposed names for Gecko releases include:
- Gecko Browser Preview 2006-06-24 (or something like that)
- restarting old Milestone system
- Mozilla Eats Babies for Lunch Pre-Pre-Alpha Developer Preview 0.0.0.1
- Target releases at web developers, not front-end testers.
- Boris proposes a *Gecko 1.9* alpha release in the near future to put
those major changes out to a wider testing audience. How this should
sync with FF2 releases is still under debate.
- Mike Connor proposes creating an update channel for Gecko testers,
pushing a new known-good trunk build every fortnight. Estimated freeze
time is one afternoon every two weeks for MozQA to run smoketests.
- Jonas notes that potential testers would not want to install an alpha
version that might wreck their bookmarks, eat their preferences and
stomp on their cookies. Changing install options so it doesn't write
to user's main FF profile might be a good idea.
My opinion:
- Plan a Gecko alpha release as Boris proposed in the first message.
- Call it "Gecko 1.9 Preview" or somesuch. The string should tie the
version number to "Gecko", not to "Gecko Browser".
- While FF development is still on the branch, don't worry too much about
syncing the releases, just make sure the front end on the trunk is stable
enough for the alpha release.
- Target the Gecko 1.9 release at web developers. Say this release is from
alpha development stages for the Firefox 3 *layout engine*, but it's still
using the same Firefox 2 front end as the FF2 builds. If testers are
interested in testing the latest layout engine from Mozilla, this is what
they should get. If they're only interested in Firefox and browsing
features, they should get the Firefox 2 branch releases.
- If we have the resources, also pick up Mike Connor's fortnightly update
channel idea. It'll make new layout engine developments that much more
easy and exciting (and thereby encourage more people to get involved with
bleeding-edge layout QA).
Basically, that follows two principles:
a) Don't try pushing the masses of testers around based on numbers.
Split them strategically based on how their skills/interests meet our
testing needs. People interested in layout engine improvements should
be poking at Gecko trunk. Everyone else should be poking at the FF2
branch.
b) Communicate clearly what the different testing builds mean.
Web developer-testers may want to have FF2 builds handy alongside
FF1.5 for testing their website for regressions, but focus on Gecko 1.9
when filing layout bugs. They can use builds more effectively if they
understand what's going on.
~fantasai
Andrew Schultz
> - Target releases at web developers, not front-end testers.
This line of reasoning is appealing (and would be ideal), but ignores
the fact that most bug reports (including layout engine bugs) are not
from web developers. They're mostly filed by users who know nothing
more than that the web page looks different than it does in IE or in the
previous version. I've probably seen about as many comments (HTML
comments by the developers) in web pages like "<!-- workaround for
Firefox -->" as I've seen bugs filed by web developers. Maybe they
assume that Firefox is defined to be "standards compliant" or maybe
they're just vastly outnumber by users.
So, we have to pitch a browser because the users don't care about the
layout engine.
What pitching to web developers /will/ get is people developing
next-generation web apps who want to take advantage of the
latest/greatest features included with Gecko 1.9. But I don't see that
as being enough.
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Jonas Sicking
>> the trunk and make sure that we get a lot of testing at some point
>> well before we're approaching any sort of freeze.
>
> The problem is that if at that point we have a number of regressions
> that make the builds not testable by the general public then we have to
> do multiple alpha cycles as the regressions are discovered. If we start
> having alphas later, we'll have fewer alpha cycles, which will, imo,
> mean fewer regressions found.
OTOH, if we have too many alphas I think people will just think "i'll
just wait another alpha and test then, it should be more stable". I
guess the answer is to find the right number of alphas and make sure to
announce to the public what the purpose of each release is.
>> I think (someone correct me if i'm overly optimistic) that we're
>> keeping good enough quality through the nightly releases that we don't
>> have a lot of test-blocking level bugs.
>
> I think you're being overly optimistic. As a simple example, I'm
> currently using a February nightly for most of my browsing; there have
> been regressions almost constantly in various functionality areas since
> then, and the switch to Cairo makes our nightlies unusably slow on my
> computer (3-4 seconds to repaint the window after I do any window
> manager operation; 1-2 seconds to repaint when the window loses or gains
> focus).
Sure, but all this is stuff that the nightlies testing is finding, no?
It's just a matter of at some point deciding to focus on fixing it
before we ship an alpha.
My question remains, if we half-ass an alpha "since we havn't released
anything in 8 months", are we really going to get a lot of new testers
on it?
/ Jonas
Jonas Sicking
>>> keeping good enough quality through the nightly releases that we
>>> don't have a lot of test-blocking level bugs.
>>
>> I think you're being overly optimistic. As a simple example, I'm
>> currently using a February nightly for most of my browsing; there have
>> been regressions almost constantly in various functionality areas
>> since then, and the switch to Cairo makes our nightlies unusably slow
>> on my computer (3-4 seconds to repaint the window after I do any
>> window manager operation; 1-2 seconds to repaint when the window loses
>> or gains focus).
>
> Sure, but all this is stuff that the nightlies testing is finding, no?
> It's just a matter of at some point deciding to focus on fixing it
> before we ship an alpha.
Actually, what I should say is, just because we find problems, it
doesn't mean that they will go away. We still have to actually fix them :)
I still think that if we just throwing more alphas out there is not
going to give us significantly higher quality than what the nightlies do.
/ Jonas
Boris Zbarsky
> I guess the answer is to find the right number of alphas and make sure to
> announce to the public what the purpose of each release is.
Exactly. For each one, list the new things that need testing.
> Sure, but all this is stuff that the nightlies testing is finding, no?
Could be; I have no idea. But the point is that if the builds are not usable
(say due to perf issues), then no one's going to test them (so we won't find
correctness bugs).
> It's just a matter of at some point deciding to focus on fixing it
> before we ship an alpha.
That point should be yesterday, imo.
> My question remains, if we half-ass an alpha "since we havn't released
> anything in 8 months", are we really going to get a lot of new testers
> on it?
My point is that we should schedule an alpha (and decide what remaining large
changes we'll take for it), then focus on getting this alpha usable so that we
can get useful testing from it. I suspect that'll take us another month or so
at least.
I'm not suggesting just shipping current trunk as-is. That would be rather
unfortunate.
-Boris
Mike Beltzner
> > 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 ;)
>
> http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan. It talks
> explicitly about testing Gecko 1.9 with the Firefox 2 front end, to
> avoid the former regressing the latter.
Precisely the bathroom wall I was referring to, actually. :) FWIW, I
didn't mean to imply that I thought this was a poor approach. Quite
the opposite, really. I'm just trying to be careful about making
assertions about relative ease and complexity when I haven't really
got the history or context to make those sorts of statements.
> So it makes no sense to release "Gecko 1.9" as some kind of library set,
> even if we had frozen APIs in place for all app front ends to use (we
> don't). A trunk Firefox alpha, with appropriately obscure name, is
> absolutely necessary well before Firefox 2 ships.
So we're back to one of the options proposed earlier in this thread.
--
/ mike beltzner / user experience lead / mozilla corporation /
Mike Beltzner
> 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
Boris Zbarsky
> -> 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
skie...@gmail.com
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.
Mike Beltzner
> 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.
Brendan Eich
> 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
Ian Pottinger
> 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
Boris Zbarsky
> 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
Boris Zbarsky
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
Mike Connor
> - 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".)
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.
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.
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.
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
Robert Kaiser
> 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
Mike Beltzner
> 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
Boris Zbarsky
> 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
Chris Hofmann
> 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.
> 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...
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.
Boris Zbarsky
> 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
Boris Zbarsky
> 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
Mike Connor
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
Chris Hofmann
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-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Boris Zbarsky
> 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
Boris Zbarsky
> 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
Christian Biesinger
:-/)
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.
Mike Shaver
> 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
Justin Kerk
@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.
--
Dopefis...@MailandNews.com is spambait
dopefish justin at gmail dot com
http://interbutt.com/
Christian Biesinger
> 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 :-)
fantasai
> On 4/14/06, fantasai <fantasa...@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
Jonas Sicking
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
Brendan Eich
> 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
Boris Zbarsky
> 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
Mike Shaver
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
Boris Zbarsky
> 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
Chris Hofmann
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 Zbarsky
> 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
Dan Veditz
> 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.
Robert Sayre
Mmm, naming. How about "Foundation"?
"Mozilla/5.0 (Windows...en-US rv:N.N) Gecko/20060308 Foundation/1.9a1"
-Rob
L. David Baron
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=334756 on doing this.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Stuart Parmenter
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
Christian Biesinger
> 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.
Boris Zbarsky
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
Jonas Sicking
>
> "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