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

Boris Zbarsky
Mike Beltzner wrote:
> I'm not sure what it means to release a trunk alpha. Is that simply a
> date towards which we work to have a reasonably stable state in the
> codebase?

That's a good question.  What I want is to release an alpha of Gecko 1.9.  The
problem, of course, is that users don't use Gecko -- they use a browser or a
mail app or whatever.  Back in the suite days, when development of front end and
back end was in sync (or rather, when there was not much front end development),
this just meant picking a time on trunk when nothing too obvious was broken,
closing the tree for a few days, making sure it passes smoketests, getting some
testing from mozillazine folks and QA for a day or two, tagging, shipping, and
reopening trunk.

At least as far as I can tell.  Asa ought to be able to expand on this if you
ask him; he was a lot more involved with it than I was.  ;)

> Since Firefox 3 is to be based on Gecko 1.9, is the idea
> that this would be equivalent to a release of Firefox 3 Alpha 1?

No.  Firefox 3 Alpha 1 would be a release that has a good bit of the Firefox 3
UI work done too.  Given that Firefox is currently working on Firefox 2, this
means that the day when that happens is a ways off.

 > As I'm often reminded, our codebase contains more than just Firefox, and
> I'm assuming we'd want people to be testing the platform, not just the
> Firefox product based on that platform.

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

> Also, I'm not sure that you want to tie the trunk release schedule into the Firefox 3 product
> release schedule ...

It's already tied to a certain extent -- we're not going to get the widespread
testing we need to call the trunk Gecko 1.9 done until we've done an alpha or
beta (or both!) of Firefox 3.

The goal, imo, of doing an alpha-type release of Gecko inside whatever the UI is
even though we're nowhere close to a Firefox 3 alpha is to catch various
regression issues so that when we _do_ ship the Firefox 3 alpha much later we
won't suddenly have 4 months worth of work of Gecko regression bugs filed...  If
we make it clear that we want testing of the rendering engine, the group we're
interested in here (web developers) might give it a spin even without new UI stuff.

Given that trunk and 1.8 branch are keeping UI in sync with each other and that
branch UI is already considered alpha-quality, I don't foresee significant
issues in terms of UI breakage holding up whatever we decide to do on trunk, right?

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

_______________________________________________
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 Connor-3
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:

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

I think that we're not ready for an alpha on trunk yet, but we do need a
way to hook people into a more-stable series of builds to get wider
testing.  We have a really awesome capability within software update to
drive a channel for more frequent testing, that we can update as
frequently (or as intermittently) as we want, based on need/relative
stability.

Taking into account the following:

* Human cost of doing "real" releases (QA/build/release mgmt)
* The bunching effect around extended freezes (lots of landings jammed)
* The goal being to get web developer types, not users, using these builds
* The general usefulness of being able to update more frequently than
our traditional release process allows
* The lack of current smoketesting

it seems like there's a lot of potential wins in running an update
channel for trunk.

I'd like to suggest the following process:

* Create an update channel for known-good nightlies (i.e. mozilla-unstable)
* Push these builds for the web developer/webapps community via MDC and
other outlets
* Every second Thursday, close the tree and do smoketests on
Windows/Linux/Mac nightlies
* This timeframe can be stretched or shrunk around major landings (i.e.
it might take a month to put trunk back in working order after the
reflow branch landing, or we might miss a major bug in the smoketest,
and want to push another build quickly)
* If those builds pass, push those into the mozilla-update channel (full
MARs only, since those require the least testing)
* CVS tagging/source tarballs are not done for these releases, since
they're already pulled by date, and this is a lot of overhead.
* No UA/versioning/branding changes should be necessary, these are not
releases, they're just better-tested/theoretically safer builds

This should, positioned correctly, get us more trunk testers with less
effort, since the effort involved in keeping up is minimized, the
smoketested builds would mean a lot less pain for people in that
channel, and because of the vastly diminished overhead, we can fit
updates to the pace of development, instead of the other way around.

-- Mike
_______________________________________________
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
Mike Connor wrote:
> Boris Zbarsky wrote:

<...>

> * Create an update channel for known-good nightlies (i.e. mozilla-unstable)
> * Push these builds for the web developer/webapps community via MDC and
> other outlets
> * Every second Thursday, close the tree and do smoketests on
> Windows/Linux/Mac nightlies

Every other week is a timeframe that is terribly hard to organize. I'd
expect that someone checks into the closed tree each and every time, and
closing the tree for one day every 14 sounds a bit intrusive to me.

I'd rather go for first whatever of the month.

> * This timeframe can be stretched or shrunk around major landings (i.e.
> it might take a month to put trunk back in working order after the
> reflow branch landing, or we might miss a major bug in the smoketest,
> and want to push another build quickly)
> * If those builds pass, push those into the mozilla-update channel (full
> MARs only, since those require the least testing)
> * CVS tagging/source tarballs are not done for these releases, since
> they're already pulled by date, and this is a lot of overhead.
> * No UA/versioning/branding changes should be necessary, these are not
> releases, they're just better-tested/theoretically safer builds
>
> This should, positioned correctly, get us more trunk testers with less
> effort, since the effort involved in keeping up is minimized, the
> smoketested builds would mean a lot less pain for people in that
> channel, and because of the vastly diminished overhead, we can fit
> updates to the pace of development, instead of the other way around.

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

Axel
_______________________________________________
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 Kaiser
In reply to this post by Boris Zbarsky
Boris Zbarsky schrieb:

> Vladimir Vukicevic wrote:
>> Cairo on the Mac is being blocked by Cocoa widgets on the mac, which
>> should get added to your list of "big changes".
>
> OK.  So the current list of pending big changes (and their status when I
> understand it) looks like:
>
> reflow branch  (status: tables being worked on, forms to be done)
> view removal
> widget removal
> Firefox on XULRunner (status: needs release engineering and installer work)
> Cocoa widgets
> Cairo on the mac (status: waiting on cocoa widgets)
> Coordinate system improvements (status: waiting on cairo)
> nsTextFrame rewrite (status: waiting on cairo for all platforms?)
>
> I feel like someone else mentioned something else but I'm forgetting
> it.... We should probably wiki this list.

Good idea.
I think though that there should be a separation of platform and
application changes ("Firefox on XULRunner" is basically an
application-only change, I guess, while the rest of the list are
platform changes).


Just for those who are interested, we also have application-specific
"big changes" on our list for SeaMonkey, which would be as follows:

consolidation of SeaMonkey-specific code in suite/
"source L10n" (support of cvs-based localization)
migration from xpfe to toolkit (with XULRunner as long-term target)

Status for all those is "started, but still in the early stages".

Robert Kaiser
_______________________________________________
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
In reply to this post by Boris Zbarsky
Mike Beltzner wrote:

> I'm assuming we'd want people to be testing the platform, not just the
> Firefox product based on that platform. Also, I'm not sure that you
> want to tie the trunk release schedule into the Firefox 3 product
> release schedule ...

I'm not sure I understand the distinction in this case. People should
*always* be "testing the platform, not just the Firefox product based on the
platform". Even for Firefox 2 there is a decent chance that safe-looking
changes in the backend or frontend code could affect the web platform, not
just the user experience.

The trunk release schedule is intimately tied up with the Firefox 3 product
schedule of necessity: it's impossible to consider doing a "platform"
release without full and integrated testing of the primary platform consumer
(Firefox). All of the trunk work is targeted at a Firefox 3 release in Q1
2007. We need to start widespread testing of underlying changes now-ish in
order to have any chance of hitting that goal.

We may not want to call it a "Firefox 3 alpha" since the frontend is largely
the same as the Firefox 2 alphas. Basically what we need to release are
"bonecho alpha frontend with gecko 1.9a backend" bits, with at least a
little expectation of stability in both pieces. In my ideal world this would
happen at about the time of bonecho alpha-2 (mid-May). Call those bits what
you will to avoid confusion.

--BDS
_______________________________________________
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 Connor-3
In reply to this post by Axel Hecht-2
Axel Hecht wrote:

> Mike Connor wrote:
>> Boris Zbarsky wrote:
>
> <...>
>
>> * Create an update channel for known-good nightlies (i.e.
>> mozilla-unstable)
>> * Push these builds for the web developer/webapps community via MDC
>> and other outlets
>> * Every second Thursday, close the tree and do smoketests on
>> Windows/Linux/Mac nightlies
>
> Every other week is a timeframe that is terribly hard to organize. I'd
> expect that someone checks into the closed tree each and every time, and
> closing the tree for one day every 14 sounds a bit intrusive to me.

What organization is needed? We close the tree for half a day to
smoketest stuff (which is basically three MozQA people for a few hours),
if things pass, we reopen the tree and dump those builds in the update
channel (preed or rhelmer can probably do this easily by now, especially
for only three builds).

The point is to spend less time frozen than we will if we're doing
bigger increments.  We used to close the tree like this five days a
week, so what makes doing it once every two weeks so intrusive?

> I'd rather go for first whatever of the month.

Its easier, sure, but it means larger changesets and larger potential
regression windows to find regressions.  It also would lead to more
bunching around freezes (needs testing, can't wait another month, etc),
which I'd like to avoid.  The point is to catch things as soon as
possible and to make checkpoints frequent enough that there isn't a big
rush to hit any particular one.

Once we get into betas I think that's entirely possible that we could
bump up to once a week, since at that stage we should be able to
consistently ship stable builds.

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

We'll still have these builds on the ftp somewhere for archiving/linking
from announcements (i.e. we would have a Gecko Team blog that we
announce these builds on, so people know what especially needs testing).

-- Mike
_______________________________________________
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 Benjamin Smedberg
On 4/12/06, Benjamin Smedberg <[hidden email]> wrote:
> The trunk release schedule is intimately tied up with the Firefox 3
> product schedule of necessity: it's impossible to consider doing a
> "platform" release without full and integrated testing of the primary
> platform consumer (Firefox). All of the trunk work is targeted at a
> Firefox 3 release in Q1 2007. We need to start widespread testing of
> underlying changes now-ish in order to have any chance of hitting that
> goal.

I guess I'm confused because I haven't really seen any firm plans
about the roadmap for Gecko 1.9, so this desire to "release" something
really looks more like a "we've been doing lots of stuff, and we want
people to poke at it" than a targeted or managed release.

While Firefox 3 is obviously a primary consumer of the platform, I
don't think we should tightly couple the release schedules. I think
the Gecko release should treat Firefox 3 as a consumer, and get
requirements in terms of scheduling and functionality just like it
would from any other consumer (such as XULRunner or Thunderbird) and
then triage and schedule appropriately. I'm not saying that it needs
to be confrontational or that the two things should work as if neither
exists, but we probably shouldn't just assume that "gecko 1.9 will be
done when Firefox 3 is released."

> the same as the Firefox 2 alphas. Basically what we need to release are
> "bonecho alpha frontend with gecko 1.9a backend" bits, with at least a
> little expectation of stability in both pieces. In my ideal world this

Exactly. I think what we're looking to release is a stable snapshot of
the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
site with all of the various applications (Fx, Tb, Sb?, XR?) that are
built off that codebase.

I want to avoid calling this a "3.0 Alpha" since those alphas should
be managed and scheduled by the groups that are focused on defining
what those v3 products will look like.

I know that I'm sort of splitting hairs here, but as we decouple the
product and platform development cycle, I think this sort of
differentiation is needed.

cheers,
mike

--

[ mike beltzner / user experience lead / mozilla corporation ]
_______________________________________________
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 Benjamin Smedberg
Mike Beltzner wrote:
> I guess I'm confused because I haven't really seen any firm plans
> about the roadmap for Gecko 1.9

Other than the feature list, I assume?

> so this desire to "release" something
> really looks more like a "we've been doing lots of stuff, and we want
> people to poke at it" than a targeted or managed release.

That's correct.  That's exactly what I want, at least.  I'm not interested in
user-facing anything here; I just want feedback on which web sites and intranet
apps we've broken so we can fix them now, and not during the release crunch.

> Exactly. I think what we're looking to release is a stable snapshot of
> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
> built off that codebase.

Yep.  And trumpet said snapshot a bit.

> I want to avoid calling this a "3.0 Alpha"

Agreed.

-Boris
_______________________________________________
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 Benjamin Smedberg
Mike Beltzner wrote:
> While Firefox 3 is obviously a primary consumer of the platform, I
> don't think we should tightly couple the release schedules. I think
> the Gecko release should treat Firefox 3 as a consumer, and get
> requirements in terms of scheduling and functionality just like it
> would from any other consumer (such as XULRunner or Thunderbird) and
> then triage and schedule appropriately.

I should note that that's filed twice already -- with Gecko 1.7 and Gecko 1.8.

The only way this can really work is if there is communication about
infrastructure changes needed by Firefox while Gecko is in an alpha cycle (or
before, e.g. if Firefox runs into issues with a given Gecko version, file bugs
so they will be fixed in the next one).

There's been a bit more of that this time around (at least in terms of Firefox
2; I have no idea what the state of Firefox 3 is), so maybe it'll all work out
this time.

Also, should we really be talking about the Gecko development cycle?  Or the
XULRunner development cycle?

> but we probably shouldn't just assume that "gecko 1.9 will be
> done when Firefox 3 is released."

Sure, but at the same time we know Gecko 1.9 will not be done until at least a
beta of Firefox 3 is released -- we need the widespread testing that will provide.

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

> Mike Beltzner wrote:
>> I guess I'm confused because I haven't really seen any firm plans
>> about the roadmap for Gecko 1.9
>
> Other than the feature list, I assume?
>
>> so this desire to "release" something
>> really looks more like a "we've been doing lots of stuff, and we want
>> people to poke at it" than a targeted or managed release.
>
> That's correct.  That's exactly what I want, at least.  I'm not
> interested in user-facing anything here; I just want feedback on which
> web sites and intranet apps we've broken so we can fix them now, and
> not during the release crunch.
The problem with this is that to get a significant level folks to use
the build long enough to provide good, in-depth, usage and feedback the
user facing parts need to be in good enough shape that they will use the
app for their daily work and extended periods of time.   So finding and
fixing up any critical user facing problems is key to getting some
testing and feedback on websites and intranet apps.

>
>> Exactly. I think what we're looking to release is a stable snapshot of
>> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
>> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
>> built off that codebase.
>
> Yep.  And trumpet said snapshot a bit.
Its going to be tough to get any widespread testing of trunk snapshot
builds named "minefield"...  I think that code name, or
characterization, or branding for trunk builds is the wrong direction to
be heading in.   We should be continuing to encourage and create a large
development and testing community of  10,000 to 20,000 or more to help
out in keeping the trunk as stable as possible at all times.  We should
be and keeping destabilizing changes away from the trunk until they are
baked and ready to land.  minefield sends the wrong message if these are
still our goals.  This becomes harder the more branches we are working
on in parallel, but I still think it is a goal.

>
>> I want to avoid calling this a "3.0 Alpha"
>
> Agreed.
>
> -Boris
> _______________________________________________
> dev-planning mailing list
> [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

Benjamin Smedberg
In reply to this post by Benjamin Smedberg
Mike Beltzner wrote:

> I guess I'm confused because I haven't really seen any firm plans
> about the roadmap for Gecko 1.9, so this desire to "release" something
> really looks more like a "we've been doing lots of stuff, and we want
> people to poke at it" than a targeted or managed release.

Perhaps I (we) don't understand what you mean by a targeted or managed
release. We had a set of goals to accomplish for "the platform", including
the reflow branch, cairo graphics, xulrunner, whatnot... we need to have
releases at various checkpoints to collect feedback/regression/performance data.

> While Firefox 3 is obviously a primary consumer of the platform, I
> don't think we should tightly couple the release schedules. I think

On the contrary, I think we absolutely *must* tightly couple the release
schedules: it is impossible to release "the platform" without thorough
testing coverage, and the only sane way to get thorough test coverage is
through Firefox releases.

> the Gecko release should treat Firefox 3 as a consumer, and get
> requirements in terms of scheduling and functionality just like it
> would from any other consumer (such as XULRunner or Thunderbird) and

If we're splitting hairs, these are very different examples. XULRunner is at
its least a build artifact of "the platform", and at most a full
productization of the platform. Thunderbird is a client app.

> exists, but we probably shouldn't just assume that "gecko 1.9 will be
> done when Firefox 3 is released."

How would you do otherwise. There is absolutely no point in releasing gecko
1.9 before Firefox 3 is finished (because the QA and testing of the platform
happens in Firefox release cycles); and it's obviously not possible to say
that gecko 1.9 could be done after FF3.

> I know that I'm sort of splitting hairs here, but as we decouple the
> product and platform development cycle, I think this sort of
> differentiation is needed.

I do not think that we have "decoupled" these cycles at all. We have put two
product cycles into a platform cycle, and made some guarantees about
platform stability between those two releases (for the benefit of the web
and the low-level extension ecosystem, primarily). That's not the same thing
at all as a decoupled schedule.

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

L. David Baron
In reply to this post by beltzner
On Wednesday 2006-04-12 15:42 -0400, Mike Beltzner wrote:
> I guess I'm confused because I haven't really seen any firm plans
> about the roadmap for Gecko 1.9, so this desire to "release" something
> really looks more like a "we've been doing lots of stuff, and we want
> people to poke at it" than a targeted or managed release.

I don't see why you think releases have to be built that way.

There are too many people working on different areas of Gecko to
coordinate in that way.  The different areas (in which developers can
swtich from one piece of code to another) often do have more detailed
plans -- in terms of what is higher and lower priority.  Then once
there's a targeted release date they know what's unsafe to do in time to
be stable for the release.  But there's no reason that the people
working on layout, DOM, or networking have to agree in advance which of
their features will make it in -- then incorrect time estimates could
easily lead to one of those groups being ready for the release 6 months
before another.  This is exactly the problem that's caused huge amounts
of tension around recent Firefox releases.

But that doesn't mean these changes don't need testing in alpha form.

> > the same as the Firefox 2 alphas. Basically what we need to release are
> > "bonecho alpha frontend with gecko 1.9a backend" bits, with at least a
> > little expectation of stability in both pieces. In my ideal world this
>
> 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

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

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

Re: Scheduling a trunk alpha

L. David Baron
In reply to this post by Chris Hofmann
On Wednesday 2006-04-12 13:10 -0700, Chris Hofmann wrote:

> Its going to be tough to get any widespread testing of trunk snapshot
> builds named "minefield"...  I think that code name, or
> characterization, or branding for trunk builds is the wrong direction 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.

-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 (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling a trunk alpha

Robert Kaiser
In reply to this post by beltzner
L. David Baron schrieb:
> I don't think this makes sense.  The vast majority of the changes that
> need widespread testing are changes that affect how we display Web
> pages.  Thus the key here is releasing a Web browser.  Releasing
> everything else would just make shipping an alpha harder, when it can
> really be something that's really easy to do, relative to most of the
> other things the build team does.

This should be Gecko test releases, right?

So why not just release a Firefox snapshot officially branded as "Gecko
Browser Preview 2006-06-24" or something like that?

The "Gecko Browser" name has been used previously for nightlies already,
and it would make clear what it's about, additionally give the "Gecko"
brand some publicity among testers and web developers.

I think though that actually providing XULRunner binaries along with
those alpha snapshots might be a good idea, so that other (possibly
external) platform users have their target for testing with newer
versions. And as Firefox (or "Gecko Browser" for that matter) should
only be an additional layer on top of a "vanilla" XULRunner, it should
probably be easy to do both packages in one run.

Robert Kaiser
_______________________________________________
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 Chris Hofmann
On 4/12/06, Chris Hofmann <[hidden email]> wrote:

> >> so this desire to "release" something
> >> really looks more like a "we've been doing lots of stuff, and we want
> >> people to poke at it" than a targeted or managed release.
> >
> > That's correct.  That's exactly what I want, at least.  I'm not
> > interested in user-facing anything here; I just want feedback on which
> > web sites and intranet apps we've broken so we can fix them now, and
> > not during the release crunch.
>
> The problem with this is that to get a significant level folks to use
> the build long enough to provide good, in-depth, usage and feedback the
> user facing parts need to be in good enough shape that they will use the
> app for their daily work and extended periods of time.   So finding and
> fixing up any critical user facing problems is key to getting some
> testing and feedback on websites and intranet apps.

Well, we're still landing all the new front end features on both the
1.8-branch and the trunk, right? So if we target this trunk release to
be coincident with a 1.8-branch release, then we shouldn't need to
worry about the user-facing parts not being good enough.

I think the issue we need to worry about is splitting our testing
community: should they be testing the browser using trunk or branch? I
can see arguments for both, really. For instance, in the short term,
the success of Firefox 2 depends on getting a lot of eyes testing
those user-facing features without having them distracted by the
platform related regressions or bustages. In the long term, as both
you and dbaron mention, we need eyes on the platform related stuff.

> >> Exactly. I think what we're looking to release is a stable snapshot of
> >> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
> >> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
> >> built off that codebase.
> >
> > Yep.  And trumpet said snapshot a bit.
> Its going to be tough to get any widespread testing of trunk snapshot
> builds named "minefield"...  I think that code name, or

I call "straw man". Nobody ever suggested that a published "release"
should be called Minefield. That name, as mentioned over and over
again in bug 308973, is intended to be used as the default branding
for apps built right off the trunk specifically to warn people that
there's no guarantee of stability. If we were to take a snapshot that
was known to be stable, we'd presumably give it a different name.

> characterization, or branding for trunk builds is the wrong direction to
> be heading in.   We should be continuing to encourage and create a large
> development and testing community of  10,000 to 20,000 or more to help
> out in keeping the trunk as stable as possible at all times.  We should

Out of curiousity, how many people are running trunk nightlies? What's
the delta we're looking to attract here?

--

[ mike beltzner / user experience lead / mozilla corporation ]
_______________________________________________
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 Connor-4
In reply to this post by Chris Hofmann
Chris Hofmann wrote:

> Boris Zbarsky wrote:
>> Mike Beltzner wrote:
>>> I guess I'm confused because I haven't really seen any firm plans
>>> about the roadmap for Gecko 1.9
>>
>> Other than the feature list, I assume?
>>
>>> so this desire to "release" something
>>> really looks more like a "we've been doing lots of stuff, and we want
>>> people to poke at it" than a targeted or managed release.
>>
>> That's correct.  That's exactly what I want, at least.  I'm not
>> interested in user-facing anything here; I just want feedback on
>> which web sites and intranet apps we've broken so we can fix them
>> now, and not during the release crunch.
> The problem with this is that to get a significant level folks to use
> the build long enough to provide good, in-depth, usage and feedback
> the user facing parts need to be in good enough shape that they will
> use the app for their daily work and extended periods of time.   So
> finding and fixing up any critical user facing problems is key to
> getting some testing and feedback on websites and intranet apps.
I think we need to resurrect dogfood and apply/enforce it aggressively,
but that doesn't change the fact that the focus of any trunk
releases/testing is the backend, and as long as the core functionality
is there, we should be ok.

>>> Exactly. I think what we're looking to release is a stable snapshot of
>>> the trunk -- we could call it Gecko 1.9 Alpha 1 -- and then fill a FTP
>>> site with all of the various applications (Fx, Tb, Sb?, XR?) that are
>>> built off that codebase.
>>
>> Yep.  And trumpet said snapshot a bit.
> Its going to be tough to get any widespread testing of trunk snapshot
> builds named "minefield"...  I think that code name, or
> characterization, or branding for trunk builds is the wrong direction
> to be heading in.   We should be continuing to encourage and create a
> large development and testing community of  10,000 to 20,000 or more
> to help out in keeping the trunk as stable as possible at all times.  
> We should be and keeping destabilizing changes away from the trunk
> until they are baked and ready to land.  minefield sends the wrong
> message if these are still our goals.  This becomes harder the more
> branches we are working on in parallel, but I still think it is a goal.
People who are going to be useful testers against ongoing Gecko
development are not going to be scared off by the fact that its called
Minefield.  Especially right now, nightlies, even more stable ones, are
going to be somewhat unpredictable, and may have grandma killing bugs we
haven't found out about.  We've absolutely done that in the past, and
will continue to do that in the future, so full disclosure even in
naming shouldn't be a problem.  If users are willing to be real dogfood
users, then the name shouldn't be a problem.  That said, doing more
parallel work would be nice, but we've optimized away from that in the
last couple of years, maybe we need to rethink that.

Based on some handwavy stats from AUS, we currently have around 6000
people using nightlies every day.  There were 12k unique users of
nightlies in the first half of March, so that really seems like we're
already mostly there.  Do we need more? More is always better, but only
if those additional users are going to file good bugs and help out in
that kind of way.  Quality, not quantity, of testing is the benchmark we
need to focus on, IMO.

-- Mike
_______________________________________________
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 Chris Hofmann
Mike Beltzner wrote:
> I think the issue we need to worry about is splitting our testing
> community: should they be testing the browser using trunk or branch?

Some of both, unfortunately.  I thought part of the point of keeping the UI in
sync was that trunk testing happening right now would still benefit Firefox 2,
so we could try to move testing resources to trunk as needed.

> In the long term, as both
> you and dbaron mention, we need eyes on the platform related stuff.

That long term is now, imo.  Again, it's been 8 months since we branched...  How
much longer term could we really get?  ;)

Back to scheduling, if we _can_ do the trunk release at about the same time as a
branch release then you're probably right that the UI should be fairly
non-busted.  So what does the branch release schedule look like?

-Boris
_______________________________________________
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 Boris Zbarsky
(reposting this to the right newsgroup)

There are a few things that I think are important.

First of all I'm worried about confusion if we release a FF 3 alpha
before FF 2 is out the door. However, this problem would be lessened a
lot, or even go away, if we name the release something other then
"Firefox 3 alpha".

Second, I think we need to make sure we get the right people to download
and test this thing. We have had a problem in the past with people not
testing heavily until it's too late to actually fix bad regressions.
Unfortunately I don't really have a good answer to this one, other than
possibly saying "don't spend time on too many alphas that don't get
heavy testing anyway". Really, do we get a lot of people testing alphas
that aren't already testing nightlies?

Lastly, I think deciding on an aimed release date is the first thing we
should do since without that anything we do is likely too early or too
late. We probably don't need to hammer out an exact date, but within a
month or two seems reasonable.

/ Jonas
_______________________________________________
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 Benjamin Smedberg
On 4/12/06, Benjamin Smedberg <[hidden email]> wrote:

> Mike Beltzner wrote:
>
> > I guess I'm confused because I haven't really seen any firm plans
> > about the roadmap for Gecko 1.9, so this desire to "release" something
> > really looks more like a "we've been doing lots of stuff, and we want
> > people to poke at it" than a targeted or managed release.
>
> Perhaps I (we) don't understand what you mean by a targeted or managed
> release. We had a set of goals to accomplish for "the platform",
> including the reflow branch, cairo graphics, xulrunner, whatnot... we
> need to have releases at various checkpoints to collect
> feedback/regression/performance data.

I mean that I don't know where the set of things that are going into
trunk is being catalogued, nor do I know where I can get a sense of
what the targets are for alphas, betas, and release candidates for the
trunk. Nor, really, do I know how those releases will be expressed,
but that seems to be precisely what we're talking about atm :)

So I'm confused about the goal: do we want to publish an alpha
release, where we set firm goals about what will or won't be in that
release, and scope priorities in terms of moving the trunk from one
milestone to the next, or do we want to simply ensure that there's a
stable state for the trunk such that people testing that code can grab
a version of their app that they can expect to not cause dataloss,
etc?

>From what I'm hearing so far, the goal is actually the latter, and I
think it's something that should definitely be done. So then it comes
down to, well, what's the best way to do that? I think we all agree
that calling it "Firefox 3 Alpha" isn't the right thing to do, since
that's gonna get misinterpreted by the general public. That was why I
suggested that we just publish those nightly builds and put them in a
directory called /latest-trunk-stable or something, and then blog and
announce that we have a set of trunk builds that are stable enough for
daily use, and would appreciate early adopters using those for their
daily surfing.

Heck, I'd even rather that people use those builds than Bon Echo
Alphas, since they'll both have the same front-end features, and
really the Bon Echo project would benefit from any bug reports that
were recieved.

> On the contrary, I think we absolutely *must* tightly couple the release
> schedules: it is impossible to release "the platform" without thorough
> testing coverage, and the only sane way to get thorough test coverage is
> through Firefox releases.

Hm, maybe you're right, and I'm being too aggressive here in my
conceptualization. What I'm getting at is that I feel like we need to
shift our way of thinking about things so that people developing the
trunk aren't forced to do so *only* in service of Firefox. So the
platform is considered to be its own product, and apps built off of it
like Firefox will pick stable-ish points from which to cut branches
that will become the base of their releases. This nets out to mostly a
semantic difference, I guess.

--

[ mike beltzner / user experience lead / mozilla corporation ]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345