Scheduling a trunk alpha

classic Classic list List threaded Threaded
96 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Scheduling a trunk alpha

Boris Zbarsky
[Re-posting to right groups now]

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

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

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

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

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

Thoughts?

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Jeff Schiller
Isn't the codename for Firefox 3 "minefield"?  At least, that's what
the nightly trunk builds are called starting 04-11.  "Mozilla Minefield
Pre-Alpha Developer Preview 1" sounds a little scary though... ;)

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Boris Zbarsky
schiller wrote:
> Isn't the codename for Firefox 3 "minefield"?  At least, that's what
> the nightly trunk builds are called starting 04-11.

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

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

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

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Philip Chee
On Tue, 11 Apr 2006 12:34:31 -0500, Boris Zbarsky wrote:

> schiller wrote:
>> Isn't the codename for Firefox 3 "minefield"?  At least, that's what
>> the nightly trunk builds are called starting 04-11.
>
> I was under the impression that we were planning to use "minefield" for all
> trunk stuff from here on out (including Gecko 1.10 work after we ship 1.9, etc).
>
>> "Mozilla Minefield Pre-Alpha Developer Preview 1" sounds a little scary though... ;)
>
> Also not really expressive of what it is, if "minefield" is to be used
> post-Gecko-1.9.

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

Phil
--
Philip Chee <[hidden email]>, <[hidden email]>
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Jeff Schiller
In reply to this post by Boris Zbarsky
> I was under the impression that we were planning to use "minefield" for all
> trunk stuff from here on out (including Gecko 1.10 work after we ship 1.9, etc).

Makes sense, actually...

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Robert O'Callahan-3
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:

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

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

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

gfx removal is not a big issue IMHO.

Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Benjamin Smedberg
Robert O'Callahan wrote:

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

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

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Robert O'Callahan-3
Benjamin Smedberg wrote:
> Robert O'Callahan wrote:
>> We're going to have to ship another alpha after the reflow branch lands,
>> whenever that is. Hopefully that will be in time for alpha2. Probably by
>> then my widget changes and nsTextFrame will be in too ... this is at
>> least a few months away.
>
> At which point we should also be able to base Firefox on XULRunner. The
> remaining pieces of that work are mostly gated on release engineering
> and some prerequisite installer work that robstrong is doing for FF2.

That will be excellent!

Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

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

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

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

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

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

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

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

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

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

gfx removal is not a big issue IMHO.

Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
  


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Boris Zbarsky
In reply to this post by Robert O'Callahan-3
Robert O'Callahan wrote:
> I think we should ship an alpha1 once we have cairo on on all platforms
> and have sorted out the absolute killer issues. Hopefully we can do this
> within a month?

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

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

> gfx removal is not a big issue IMHO.

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

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Boris Zbarsky
In reply to this post by Robert O'Callahan-3
Chris Hofmann wrote:
> There are about 77 new bugs filed with the regression keyword in the
> last 6 weeks.  Many owned by nobody.
...
> About 12 or these have some kind of  1.9a1  nomination or blocker flag

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

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

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

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

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

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

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Vladimir Vukicevic-2
In reply to this post by 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".  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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Robert O'Callahan-3
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:
> As I see it, it's something with a certain amount of regression
> likelihood as APIs impedance-match in the move from gfx to thebes; both
> in terms of performance and in terms of functionality (silly things like
> different arg orders for functions that do similar things or whatnot).

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

Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Chris Hofmann
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:
>  
>
> I've been setting this on various regressions I run into...
>
> What I think I'd really like is to be able to set the following flags
> today:
>
> blocking1.9a1?
> blocking1.9a2?
Marcia added a2 as another bucket to throw things in for now.
> blocking1.9b1?
> blocking1.9?
>
I guess if we knew that this is what the rest of the milestone schedule
looked like we could set those up as well.

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


> I

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Peter van der Woude
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:
> 68 bugs are on the blocker/nomination list right now, with many of these
> looking like regressions, but from longer than 6 weeks ago

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

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

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

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Boris Zbarsky
In reply to this post by Vladimir Vukicevic-2
Vladimir Vukicevic wrote:
> Cairo on the Mac is being blocked by Cocoa widgets on the mac, which
> should get added to your list of "big changes".

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

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

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

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

OK.  Who would?  Josh?

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

I meant removal of the gfx interfaces yeah.

> that simply won't happen before alpha1

That was more or less what I thought, yeah.

> it might not even happen before Fx3

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

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

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

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

Thanks for the info!

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Boris Zbarsky
In reply to this post by Boris Zbarsky
Chris Hofmann wrote:
> Do we agreed  that that is what the backend of the milestone schedule
> looks like for getting to 1.9 final?  I think getting a1 and a2
> milestones sorted out and triaged would tell us if we are on the path to
> having the next milestone be b1 or possibly needing an a3...

That makes some sense to me.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

beltzner
In reply to this post by Boris Zbarsky
> when we _do_ plan to have a trunk alpha.  The 1.8 branch branched on

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

cheers,
mike

--

[ mike beltzner / user experience lead / mozilla corporation ]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Axel Hecht-2
In reply to this post by Boris Zbarsky
Chris Hofmann wrote:

> Boris Zbarsky wrote:
>>  
>>
>> I've been setting this on various regressions I run into...
>>
>> What I think I'd really like is to be able to set the following flags
>> today:
>>
>> blocking1.9a1?
>> blocking1.9a2?
> Marcia added a2 as another bucket to throw things in for now.
>> blocking1.9b1?
>> blocking1.9?
>>
> I guess if we knew that this is what the rest of the milestone schedule
> looked like we could set those up as well.
>
> Do we agreed  that that is what the backend of the milestone schedule
> looks like for getting to 1.9 final?  I think getting a1 and a2
> milestones sorted out and triaged would tell us if we are on the path to
> having the next milestone be b1 or possibly needing an a3...

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

Axel
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Robert O'Callahan-3
In reply to this post by Vladimir Vukicevic-2
Vladimir Vukicevic wrote:

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

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

Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345