Scheduling a trunk alpha

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

Re: Scheduling a trunk alpha

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

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

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

But I'm glad you agree :-)
_______________________________________________
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: selective summary

fantasai
In reply to this post by fantasai
Mike Beltzner wrote:

> On 4/14/06, fantasai <[hidden email]> 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
_______________________________________________
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

Jonas Sicking
In reply to this post by Brendan Eich
Brendan Eich wrote:

> Jonas Sicking wrote:
>> Boris Zbarsky wrote:
>>> Mike Beltzner wrote:
>>>> I think the issue we need to worry about is splitting our testing
>>>> community: should they be testing the browser using trunk or branch?
>>>
>>> Some of both, unfortunately.  I thought part of the point of keeping
>>> the UI in sync was that trunk testing happening right now would still
>>> benefit Firefox 2, so we could try to move testing resources to trunk
>>> as needed.
>>
>> I'm not sure that there is a huge advantage in shipping an alpha now,
>> as opposed to shipping one a bit after FF2 is out the door.
>> Regressions are generally not too hard to fix, it is finding them that
>> is the problem. So it might not be too bad to live with a regression a
>> bit longer on the trunk and make sure that we get a lot of testing at
>> some point well before we're approaching any sort of freeze.
>
> This is contradicted by our experience over the years, especially during
> the push to Firefox 1.0 when 1.8 alpha lingered on the trunk.  But we
> have always had problems with regressions diving deep, entangling with
> other changes.
>
> What you write above "live with a regression a bit longer" implies that
> regressions are known and tracked, and fixing them can be deferred. That
> is not the case.  Too often, regressions are not even *found* until an
> alpha-scale (100k+ downloads) release is done -- and then the hard job
> of diagnosing begins.  This can take months.

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

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

/ Jonas
_______________________________________________
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

Brendan Eich
Jonas Sicking wrote:

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

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

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

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

Agreed.

/be
_______________________________________________
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:
> 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
_______________________________________________
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

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

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

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

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

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

Thursday 11:00a PDT

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

> -Boris
> _______________________________________________
> dev-planning mailing list
> [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 Boris Zbarsky
Chris Hofmann wrote:
> If we can get to something that
> approaches platform partity soon I think that should be the focus.  

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

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

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

-Boris
_______________________________________________
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: selective summary

Daniel Veditz
In reply to this post by Robert Kaiser
Robert Kaiser wrote:
> If the UA string would show "Minefield/20060528" instead of
> "Firefox/3.0a" this might be less the fact...

We absolutely do not want the UA to say Firefox-anything until it's
ready for Firefox end-users.
_______________________________________________
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: selective summary

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

Mmm, naming. How about "Foundation"?

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

-Rob
_______________________________________________
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: selective summary

L. David Baron
In reply to this post by Robert Kaiser
On Tuesday 2006-04-18 19:40 +0200, Robert Kaiser wrote:

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

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha: selective summary

Stuart Parmenter-3
In reply to this post by Boris Zbarsky
So I was just told about this thread for the first time, so sorry I'm
late to the game.

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

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

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

stuart

_______________________________________________
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: selective summary

Christian Biesinger
In reply to this post by Rob Sayre-2
Robert Sayre wrote:
> Mmm, naming. How about "Foundation"?
>
> "Mozilla/5.0 (Windows...en-US rv:N.N) Gecko/20060308 Foundation/1.9a1"

Or that part could just be removed from the useragent string... the
1.9a1 part is already in the rv: string.
_______________________________________________
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
Figured folks should know what our testing situation on trunk and branch looks
like to some who're doing it.  They've been pretty under-represented in this
discussion.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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