Firefox "Lorentz" and 1.9.2/1.9.3

25 views
Skip to first unread message

Benjamin Smedberg

unread,
Dec 29, 2009, 1:46:20 PM12/29/09
to
Because information and proposals have been trickling out through the wiki
pages and the weekly meeting notes, I'd like to follow up with a longer-form
version of why I think we should do Firefox "Lorentz" in March 2010 based
off of the 1.9.2 branch.

At the Firefox work week I sat at a whiteboard with Beltzner and some others
thinking about the features that the Firefox team wants to ship in 2010:

* Crash-safe plugins (OOPP)
* Transition to jetpack extensions
* New UI "stuff": the new menu/toolbar structure and platform integration
* Weave
* Updater which doesn't interrupt the user
* More responsive UI (async I/O, primarily)
* Better startup time
* Integrated developer tools

From a user point of view, some of these changes are non-disruptive, while
some are definitely disruptive. The non-user-disruptive changes are:

* Crash-safe plugins (OOPP)
* Updater which doesn't interrupt the user
* More responsive UI (async I/O, primarily)
* Better startup time

The desire is to get these features into the hands of users as quickly as
pratical. These changes will still require a large beta with 600k+ users.
The code name for this release is Firefox "Lorentz".

The other features, especially the new menu/toolbar UI structure and
integrated jetpack, aren't going to be ready to go to beta until June, and
are going to require extensive user feedback cycles after that.

Given these constraints, we have two options: we could ship the "Lorentz"
release from 1.9.2, backporting the new changes. Or we could do a release
off of mozilla-central/1.9.3.

I believe that backporting the OOPP work to 1.9.2 is a task whose scope and
schedule implications are fairly well-known: the changes are limited in
scope to a few existing files and the new IPC code. Most of the other
changes (apart from the updater) have already landed on trunk and can be
backported with minimal pain. In addition, we can mitigate risk for plugins
by controlling which plugins are run out-of-process, using either a
whitelist or a blacklist. With the project branch, I believe we could go to
beta in the middle of January and release in late March/early April without
disrupting the regular cycle of 3.6 security and stability releases. There
are some issues to work out around localization changes on a stable branch,
but I don't believe these will be insurmountable.

Doing a release from mozilla-central/1.9.3 presents a lot of schedule risk
without matching reward. We would probably have to un-do changes that have
already been made, such as the OJI plugin support removal as well as support
for MacOS 10.4. Even if we went to beta in mid-January, the schedule needed
to stabilize that branch for final release is much less clear. Doing a
release from 1.9.3 also increases the risk of having to do a minor update
due to extension compatibility from API and UI changes.

Do the content/layout/JS groups have similar lists of features to ship in
2010? It would be worthwhile to see whether/how they would fit into the
proposed release structure. For example, the Direct2D rendering backend is
fairly self-contained; could it land in the Lorentz timeframe on 1.9.2? SMIL
and WebGL seem like possible candidates as well.

From a long-term perspective, I think that we'd love to be able to do
quicker minor updates from the main "mozilla-central" tree, and
transitioning from the current overlay/inject extension architecture to a
jetpack is a key part of this plan. But until that is accomplished, I don't
think short-cycle releases from mozilla-central are realistic.

It's also important to note that the current Lorentz plan doesn't have to be
a single landing-point. If OOPP is ready in March but the updater isn't
ready until April, they could land in different dot releases (Firefox 3.6.2
and 3.6.3).

With the 1.9.2-lorentz project branch, I think that we will have the best
balance of controlling risk and gaining confidence in new features, and that
ultimately that can help redefine our notion of what it means to land
something on a stable branch.

--BDS

Benjamin Smedberg

unread,
Dec 29, 2009, 1:56:24 PM12/29/09
to
On 12/29/09 1:46 PM, Benjamin Smedberg wrote:
> Because information and proposals have been trickling out through the
> wiki pages and the weekly meeting notes, I'd like to follow up with a
> longer-form version of why I think we should do Firefox "Lorentz" in
> March 2010 based off of the 1.9.2 branch.

The draft diagrams to go with this post are at

https://wiki.mozilla.org/Talk:Firefox/Roadmap

--BDS


John J. Barton

unread,
Dec 29, 2009, 2:26:34 PM12/29/09
to
Benjamin Smedberg wrote:
...

> Given these constraints, we have two options: we could ship the
> "Lorentz" release from 1.9.2, backporting the new changes. Or we could
> do a release off of mozilla-central/1.9.3.

Will the Firefox release be 3.6.X and Firefox 3.6 compatible addons work
with the proposed release?

(BTW 'electrolysis' is chemistry, not physics, so we'd rather see the
release named "Davy" or "Faraday" or "Nicholson" or "Carlisle").


jjb

Shawn Wilsher

unread,
Dec 29, 2009, 2:19:03 PM12/29/09
to dev-pl...@lists.mozilla.org
On 12/29/2009 11:26 AM, John J. Barton wrote:
> (BTW 'electrolysis' is chemistry, not physics, so we'd rather see the
> release named "Davy" or "Faraday" or "Nicholson" or "Carlisle").
It's http://en.wikipedia.org/wiki/Lorentz_National_Park, not
http://en.wikipedia.org/wiki/Hendrik_Lorentz. Firefox code names are
parks ;)

Cheers,

Shawn

Robert Accettura

unread,
Dec 29, 2009, 2:29:42 PM12/29/09
to Shawn Wilsher, dev-pl...@lists.mozilla.org
On Tue, Dec 29, 2009 at 2:19 PM, Shawn Wilsher <sdw...@mozilla.com> wrote:

> On 12/29/2009 11:26 AM, John J. Barton wrote:
>

>> (BTW 'electrolysis' is chemistry, not physics, so we'd rather see the
>> release named "Davy" or "Faraday" or "Nicholson" or "Carlisle").
>>

> Compromise: http://www.chemicalparksarnia.com

Bonus: Canadian

--
Robert Accettura
rob...@accettura.com

Christopher Blizzard

unread,
Dec 29, 2009, 5:21:17 PM12/29/09
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
On 12/29/2009 1:46 PM, Benjamin Smedberg wrote:
>
> Do the content/layout/JS groups have similar lists of features to ship
> in 2010? It would be worthwhile to see whether/how they would fit into
> the proposed release structure. For example, the Direct2D rendering
> backend is fairly self-contained; could it land in the Lorentz
> timeframe on 1.9.2? SMIL and WebGL seem like possible candidates as well.

I have a list of things that were important for developers.

1. CSS Transitions (this is top of my list right now, esp as we reach
into mobile.)
2. WebSockets (has patch, needs (final?) review.)

Plus performance, performance, performance.

dbaron has most of the Transitions work done, I believe, in a
combination of stuff on -central and in his own tree - no idea what he
thinks the impact and risk is there or if it's very self-contained.

WebSockets seems reasonably self-contained, at least in my
understanding, with a small web-facing API.

I would love to have Direct2D on that train - as Shaver said, it's like
a whole different browser.

We need to make sure this train doesn't get too big, though, or it will
stretch out into a pretty long release.

--Chris

Boris Zbarsky

unread,
Dec 29, 2009, 6:22:03 PM12/29/09
to
On 12/29/09 5:21 PM, Christopher Blizzard wrote:
> dbaron has most of the Transitions work done, I believe, in a
> combination of stuff on -central and in his own tree - no idea what he
> thinks the impact and risk is there or if it's very self-contained.

I'll let dbaron handle this (though I happen to think it's not that
self-contained; I wouldn't want to try backporting it to 1.9.2).

> WebSockets seems reasonably self-contained, at least in my
> understanding, with a small web-facing API.

And a pretty major refactoring of all the HTTP auth code to make it
reusable for websockets. Not self-contained at all, in fact.

And a lot of the performance work in layout and DOM that's been
happening on m-c is not exactly backportable easily either. I can't
speak for jseng.

-Boris

John J. Barton

unread,
Dec 29, 2009, 6:52:29 PM12/29/09
to
Benjamin Smedberg wrote:
...>

> From a long-term perspective, I think that we'd love to be able to do
> quicker minor updates from the main "mozilla-central" tree, and
> transitioning from the current overlay/inject extension architecture to
> a jetpack is a key part of this plan. But until that is accomplished, I
> don't think short-cycle releases from mozilla-central are realistic.

As Firebug is a overlay/injection extension I'm puzzled by any
connection between this architecture and the release cycle. What about
this architecture causes long cycles?

> With the 1.9.2-lorentz project branch, I think that we will have the
> best balance of controlling risk and gaining confidence in new features,
> and that ultimately that can help redefine our notion of what it means
> to land something on a stable branch.

I'm worried about the opposite: redefinition of 'trunk'. The March
release slips to June, important features are proposed for stable branch
in Sept...

jjb

L. David Baron

unread,
Dec 29, 2009, 7:20:49 PM12/29/09
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Tuesday 2009-12-29 18:22 -0500, Boris Zbarsky wrote:
> On 12/29/09 5:21 PM, Christopher Blizzard wrote:
> >dbaron has most of the Transitions work done, I believe, in a
> >combination of stuff on -central and in his own tree - no idea what he
> >thinks the impact and risk is there or if it's very self-contained.
>
> I'll let dbaron handle this (though I happen to think it's not that
> self-contained; I wouldn't want to try backporting it to 1.9.2).

There are patches it depends on that touch other areas of code, and
some of the transitions patches touch a bit of other code, but I
think backporting is relatively doable if we're willing to also port
over the patches it depends on or the relevant pieces of them.

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

Justin Dolske

unread,
Dec 29, 2009, 8:11:39 PM12/29/09
to
On 12/29/09 2:21 PM, Christopher Blizzard wrote:

>> For example, the Direct2D rendering
>> backend is fairly self-contained; could it land in the Lorentz
>> timeframe on 1.9.2? SMIL and WebGL seem like possible candidates as well.
>
> I have a list of things that were important for developers.

> [...]

I think we need to be rather ruthless about limiting the scope of what
goes into Lorentz.... For a few reasons: (1) prevent schedule slip (2)
avoid slowing trunk development by spending time backporting and (3)
reduce risk of breakage in a minor update.

Especially the last point. We've had issues with bad updates in our
already tightly-scoped "security/stability only" releases. I think
exploring ways to bring stuff to users quicker is fantastic, but we
should resist the temptation -- especially for this first time -- to
pile in extra stuff in while we're there.

My impression (and maybe I'm wrong, or this was lost in bsmedberg's
post) was that in some respect we shouldn't think about Lorentz as a new
release, but as backporting super-high-value features (like OOPP) to the
stable release -- with all the Tread Carefully that entails. Maybe there
are a few other such features we could do this with (as an experiment,
if nothing else), but if OOPP is the only thing to ever ship this way
I'd be ok with that.

Justin

Boris Zbarsky

unread,
Dec 29, 2009, 8:23:31 PM12/29/09
to
On 12/29/09 6:52 PM, John J. Barton wrote:
> As Firebug is a overlay/injection extension I'm puzzled by any
> connection between this architecture and the release cycle. What about
> this architecture causes long cycles?

The breadth of the extension API (all XPCOM interfaces, plus the entire
browser UI, basically), which means that we have to have a maxVersion
setup with the maxVersion getting bumped on each release, which means
that all the extensions have to be updated to be compatible with the new
release. This takes a long time, typically.

The long-term goal is to be able to have major updates that don't break
at least jetpack extensions (in the sense that whatever jetpacks the
user has installed just keep working with no changes needed to them).
Firebug would probabl need to be updated for every release, as now...
(at least insofar as bumping up maxVersion).

> I'm worried about the opposite: redefinition of 'trunk'. The March
> release slips to June, important features are proposed for stable branch
> in Sept...

This is a somewhat separate problem, and yes one made worse by long
release cycles...

-Boris

Daniel Holbert

unread,
Dec 29, 2009, 8:39:46 PM12/29/09
to dev-pl...@lists.mozilla.org, Benjamin Smedberg
On 12/29/2009 10:46 AM, Benjamin Smedberg wrote:
> Do the content/layout/JS groups have similar lists of features to ship
> in 2010? It would be worthwhile to see whether/how they would fit into
> the proposed release structure. For example, the Direct2D rendering
> backend is fairly self-contained; could it land in the Lorentz timeframe
> on 1.9.2? SMIL and WebGL seem like possible candidates as well.

SMIL could be backportable, if we do CSS transitions. It's pretty
self-contained, and a lot of it is already in 1.9.2 (but disabled with a
build switch). The main not-self-contained part is the interpolation
code in the style system, which is shared with CSS transitions.

~Daniel

John J. Barton

unread,
Dec 29, 2009, 11:28:50 PM12/29/09
to
Boris Zbarsky wrote:
> On 12/29/09 6:52 PM, John J. Barton wrote:
>> As Firebug is a overlay/injection extension I'm puzzled by any
>> connection between this architecture and the release cycle. What about
>> this architecture causes long cycles?
>
> The breadth of the extension API (all XPCOM interfaces, plus the entire
> browser UI, basically), which means that we have to have a maxVersion
> setup with the maxVersion getting bumped on each release, which means
> that all the extensions have to be updated to be compatible with the new
> release. This takes a long time, typically.

Then I would say that the problem in the architecture is mixing binary
and JS compatibility. Adding a (deeper) shim JS layer would allow
decoupling, increasing the amount of binary change before a maxVersion
change above the shim layer.

>
> The long-term goal is to be able to have major updates that don't break
> at least jetpack extensions (in the sense that whatever jetpacks the
> user has installed just keep working with no changes needed to them).

I think jetpack is terrific innovation in better dynamics and modern
packaging. It also re-interfaces the platform. In my opinion, that part
way more effort than makes sense. In particular, using a shim JS layer
would solve the problem faster and cheaper. Many parts of the current
API could be improved, but not by arbitrarily introducing new API.

jjb

Boris Zbarsky

unread,
Dec 29, 2009, 11:29:00 PM12/29/09
to
On 12/29/09 11:28 PM, John J. Barton wrote:
>> The breadth of the extension API (all XPCOM interfaces, plus the
>> entire browser UI, basically), which means that we have to have a
>> maxVersion setup with the maxVersion getting bumped on each release,
>> which means that all the extensions have to be updated to be
>> compatible with the new release. This takes a long time, typically.
>
> Then I would say that the problem in the architecture is mixing binary
> and JS compatibility. Adding a (deeper) shim JS layer would allow
> decoupling, increasing the amount of binary change before a maxVersion
> change above the shim layer.

It's not a matter of binary compat. That's actually very rarely a
problem. Right now any change to any .xul file in Firefox needs a
maxVersion bump, because the way overlays and the existing extension JS
code tend to work is by assuming things about the XUL DOM. As soon as
it changes you lose compat.

The solution, though is right: a new extension API that is more limited
in terms of what you can do and hence easier to preserve across
underlying changes.

> I think jetpack is terrific innovation in better dynamics and modern
> packaging. It also re-interfaces the platform. In my opinion, that part
> way more effort than makes sense. In particular, using a shim JS layer
> would solve the problem faster and cheaper. Many parts of the current
> API could be improved, but not by arbitrarily introducing new API.

That sounds like a great topic for a jetpack-specific thread.

-Boris


John J. Barton

unread,
Dec 30, 2009, 12:09:58 AM12/30/09
to
Boris Zbarsky wrote:
> On 12/29/09 11:28 PM, John J. Barton wrote:
>>> The breadth of the extension API (all XPCOM interfaces, plus the
>>> entire browser UI, basically), which means that we have to have a
>>> maxVersion setup with the maxVersion getting bumped on each release,
>>> which means that all the extensions have to be updated to be
>>> compatible with the new release. This takes a long time, typically.
>>
>> Then I would say that the problem in the architecture is mixing binary
>> and JS compatibility. Adding a (deeper) shim JS layer would allow
>> decoupling, increasing the amount of binary change before a maxVersion
>> change above the shim layer.
>
> It's not a matter of binary compat. That's actually very rarely a
> problem. Right now any change to any .xul file in Firefox needs a
> maxVersion bump, because the way overlays and the existing extension JS
> code tend to work is by assuming things about the XUL DOM. As soon as
> it changes you lose compat.

Excellent news, that means the problem is even smaller. We should take
advantage of this. We only need only to replace the overlay mechanism
with eg jetpack-isms. Not XPCOM, not the whole enchilada.

>
> The solution, though is right: a new extension API that is more limited
> in terms of what you can do and hence easier to preserve across
> underlying changes.

Yes, extensions that can't do anything useful can be preserved, no
problem. For the rest, I think this is wishful thinking, and opposite to
the CanDoAnything model that makes extensions in Mozilla successful.

>
>> I think jetpack is terrific innovation in better dynamics and modern
>> packaging. It also re-interfaces the platform. In my opinion, that part
>> way more effort than makes sense. In particular, using a shim JS layer
>> would solve the problem faster and cheaper. Many parts of the current
>> API could be improved, but not by arbitrarily introducing new API.
>
> That sounds like a great topic for a jetpack-specific thread.

But the proposal is to wait for jetpack to get faster trunk cycles. I
say that we should not make that gamble. That is the opposite of
jetpack-specific ;-)

jjb

Philip Chee

unread,
Dec 30, 2009, 12:18:39 AM12/30/09
to

And here I was wondering which wildlife park/reserve was named "Lorentz".


Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

John J. Barton

unread,
Dec 30, 2009, 12:55:12 AM12/30/09
to
Philip Chee wrote:
> On Tue, 29 Dec 2009 11:26:34 -0800, John J. Barton wrote:
>> Benjamin Smedberg wrote:
>> ...
>>> Given these constraints, we have two options: we could ship the
>>> "Lorentz" release from 1.9.2, backporting the new changes. Or we could
>>> do a release off of mozilla-central/1.9.3.
>> Will the Firefox release be 3.6.X and Firefox 3.6 compatible addons work
>> with the proposed release?
>>
>> (BTW 'electrolysis' is chemistry, not physics, so we'd rather see the
>> release named "Davy" or "Faraday" or "Nicholson" or "Carlisle").
>
> And here I was wondering which wildlife park/reserve was named "Lorentz".

Please pardon my aside, I should know better. How about the on-topic
question?

jjb

Gordon P. Hemsley

unread,
Dec 30, 2009, 4:24:36 AM12/30/09
to
As a Mac OS X 10.4 user with no current plans to upgrade, ideally I'd
prefer (FWIW) as many features backported to 3.6 as possible.

On the other hand, I agree with Justin:

On Dec 29, 8:11 pm, Justin Dolske <dol...@mozilla.com> wrote:
> if OOPP is the only thing to ever ship this way
> I'd be ok with that.

Gordon

Robert Kaiser

unread,
Dec 30, 2009, 3:03:04 PM12/30/09
to
Benjamin Smedberg wrote:
> Doing a release from mozilla-central/1.9.3 presents a lot of schedule
> risk without matching reward.

Not doing it is a big schedule risk for anyone who had already planned
to base their work on a 1.9.3 release in June/July.
And this is my fear - I don't see SeaMonkey ready for a release before
May or June at least, and we have no 1.9.2 testing whatsoever yet, we
also will (optimistically) need about 3 months before we even have build
machine capacity to even cover an additional branch, given the
experience I have of requesting machines and getting them after long
discussions. And we want to get nearer to being in sync with Firefox
with new releases on new Gecko/Mozilla platforms.
With the original plan for 1.9.3, that looked possible, with the
"Lorentz" plans I see us failing there and staying a few months behind
everything FF does, which is clearly not what we want.

In a greater picture, if we want others to build on the Mozilla
platform, we need to provide somewhat reliable plans, and dropping the
January branch and June release for some time-expensive stuffing of
things into the current stable branch and making it more unstable,
putting the next bigger release in very late 2010 or even 2011 is not
really what helps those parties.

> We would probably have to un-do changes
> that have already been made, such as the OJI plugin support removal as
> well as support for MacOS 10.4.

Then either those steps were probably premature in the first place or
you are painting the old plans black to make yours look shinier.

Robert Kaiser

Robert O'Callahan

unread,
Dec 30, 2009, 5:13:21 PM12/30/09
to
On 30/12/09 2:11 PM, Justin Dolske wrote:
> I think we need to be rather ruthless about limiting the scope of what
> goes into Lorentz.... For a few reasons: (1) prevent schedule slip (2)
> avoid slowing trunk development by spending time backporting and (3)
> reduce risk of breakage in a minor update.

I totally agree.

Rob

Robert O'Callahan

unread,
Dec 30, 2009, 5:23:45 PM12/30/09
to
On 30/12/09 2:39 PM, Daniel Holbert wrote:
> SMIL could be backportable, if we do CSS transitions. It's pretty
> self-contained, and a lot of it is already in 1.9.2 (but disabled with a
> build switch). The main not-self-contained part is the interpolation
> code in the style system, which is shared with CSS transitions.

I don't think we should backport SMIL or CSS transitions, personally. In
the long run, backporting is a lose, so we should only backport things
that are extremely high value. IMHO the excitement around new Web
platform features focuses on what's on trunk, not so much what we're
actually shipping in stable releases, so generally backporting them is
not high value.

Rob

Robert O'Callahan

unread,
Dec 30, 2009, 5:30:45 PM12/30/09
to
On 30/12/09 7:46 AM, Benjamin Smedberg wrote:
> I believe that backporting the OOPP work to 1.9.2 is a task whose scope
> and schedule implications are fairly well-known: the changes are limited
> in scope to a few existing files and the new IPC code. Most of the other
> changes (apart from the updater) have already landed on trunk and can be
> backported with minimal pain. In addition, we can mitigate risk for
> plugins by controlling which plugins are run out-of-process, using
> either a whitelist or a blacklist.

As I just wrote in another message, if we whitelist --- especially if
the list contains only Flash --- I think this is an OK plan. I suspect
making "unknown" plugins OOP would end up requiring a much longer test
and stabilization cycle than you want.

> For example, the Direct2D rendering backend is fairly self-contained;
> could it land in the Lorentz timeframe
> on 1.9.2? SMIL and WebGL seem like possible candidates as well.

I think we should consider D2D, although there are some potential
issues, like which drivers and hardware we would enable it for.

I don't think SMIL, CSS Transitions, WebGL or Web Sockets are worth
considering. As I just wrote in another message, I think the difference
in value between "on trunk" and "shipped to users" is a lot lower for
Web platform features than for user-facing features. WebGL also has
unresolved issues that we can't ship with.

Rob

L. David Baron

unread,
Dec 31, 2009, 10:31:51 AM12/31/09
to dev-pl...@lists.mozilla.org
On Tuesday 2009-12-29 13:46 -0500, Benjamin Smedberg wrote:
> Because information and proposals have been trickling out through
> the wiki pages and the weekly meeting notes, I'd like to follow up
> with a longer-form version of why I think we should do Firefox
> "Lorentz" in March 2010 based off of the 1.9.2 branch.
>
> At the Firefox work week I sat at a whiteboard with Beltzner and
> some others thinking about the features that the Firefox team wants
> to ship in 2010:
>
> * Crash-safe plugins (OOPP)
> * Transition to jetpack extensions
> * New UI "stuff": the new menu/toolbar structure and platform integration
> * Weave
> * Updater which doesn't interrupt the user
> * More responsive UI (async I/O, primarily)
> * Better startup time
> * Integrated developer tools
>
> From a user point of view, some of these changes are non-disruptive,
> while some are definitely disruptive. The non-user-disruptive
> changes are:
>
> * Crash-safe plugins (OOPP)
> * Updater which doesn't interrupt the user
> * More responsive UI (async I/O, primarily)
> * Better startup time

I think when we discuss our plans for Firefox releases, we should
also think about what platform features we want to ship, and when.
Platform features are important because (1) the capabilities
supported by the Web platform affect people's choices between
developing Web applications and developing applications on other
platforms and (2) perception of our leadership in Web platform
features affects our ability to influence the design of the Web
platform in directions we care about (user control, security, etc.).


I have bad feelings about this plan based on the last time we did
this: Firefox 2.0 sucked resources away from the trunk and allowed
it to become extremely unstable, and it look a long time to get
things back together for Firefox 3.

If we're serious about not doing that this time, then we need to put
significant resources into moving mozilla-central development
forward simultaneously with Lorentz: this means planning the next
release, shipping alphas (I think we should do 1.9.3a1 in January),
and setting a clear target for when we expect to ship (I'd hope
summer of 2010 at the latest).

I think having a clear plan for shipping mozilla-central is also
very important to show all the contributors who aren't working on
one of the small number of things that are part of Lorentz that
their work is valued.

It's also important because the bigger the gaps we make between
releases (especially unexpected gaps), the harder we make it to ship
any individual release, because people try to cram more stuff into
it (given that the next one is indefinitely far away).

Boris Zbarsky

unread,
Dec 31, 2009, 2:38:51 PM12/31/09
to
On 12/29/09 1:46 PM, Benjamin Smedberg wrote:
> Do the content/layout/JS groups have similar lists of features to ship
> in 2010?

I just looked at the post-branch changes I've made so far on m-c, more
or less, [1] and those that aren't security fixes tend to be performance
and architecture work. It's possible to backport some of the latter,
with enough pain, but I don't think moving it up by 3 months is worth
the time investment. That assumes, of course, that we still plan to be
shipping Gecko 1.9.3 as planned sometime in early summer 2010. Which I
sincerely hope we are.

My general feeling is that most of the recent content/layout work falls
into similar buckets.

> It would be worthwhile to see whether/how they would fit into
> the proposed release structure.

This would have been a good question to ask 6 months ago when planning
and time prioritization for this various work was happening...

In general, I think getting our newest-and-best layout features into an
alpha and out there is almost as important as getting it into a shipping
release. Possibly more important in some cases in terms of the hype and
marketing effects (sad, but true). Getting in our performance
improvements is in a similar position, but with betas, not alphas -- a
lot of the comparisons people are making are between betas, not shipping
releases. A lot of the web developer hype seems to be about alphas, not
shipping releases.

> But until that is accomplished, I
> don't think short-cycle releases from mozilla-central are realistic.

Shorter than the 1.9.1 to 1.9.2 cycle? In general, the current plan is
for the 1.9.2 to 1.9.3 cycle to be about the same length as that, right?

> It's also important to note that the current Lorentz plan doesn't
> have to be a single landing-point. If OOPP is ready in March but
> the updater isn't ready until April, they could land in different dot
> releases (Firefox 3.6.2 and 3.6.3).

This seems perfectly reasonable to me, sure.

To be clear, I can see why we want to land OOPP on 1.9.2.x. I think
it'll take some work, but it might be worth it (probably is) for the
immediate boost to stability and user experience. I don't think
backporting random layout/DOM architecture work makes sense, and I don't
think that it makes sense to try to disentangle features that landed
after architecture work from said architecture work, in terms of time
investment. Better to aggressively work on developing and stabilizing
1.9.3, with the explicit goal of shipping it in early summer 2010.
David's proposal of a 1.9.3a1 in January makes a lot of sense to me.

One other note: one issue as I see it is that we have several different
audiences we're targeting: the mass of our users, early-adopter users,
and web developers (some overlap between these last two). They're
looking for slightly different things, and are actually best served by
different release schedules... Hence the tension we're seeing here.

-Boris


[1]
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-08-13&enddate=2010-01-01&user=bzba...@mozilla.com
is the set of changes I pushed; some of these were not authored by me.

Uli Link

unread,
Jan 1, 2010, 12:17:47 PM1/1/10
to
Boris Zbarsky schrieb:

> One other note: one issue as I see it is that we have several different
> audiences we're targeting: the mass of our users, early-adopter users,
> and web developers (some overlap between these last two). They're
> looking for slightly different things, and are actually best served by
> different release schedules... Hence the tension we're seeing here.

Enterprise customer deployments?
They won't follow a major-release-every-9-month schedule very long.
Capacity divided by the number of still supported branches gives an
estimate of a maximum lifetime from branching to EoL which is ALWAYS too
short for conservative Enterprise customers.
Maybe something like the Ubuntu or Fedora/RedHat model with shortlived
branches and only few long term support branches with security fixes only?

--
ULi

Boris Zbarsky

unread,
Jan 1, 2010, 1:20:11 PM1/1/10
to
On 1/1/10 12:17 PM, Uli Link wrote:
> Enterprise customer deployments?

Last I checked, those were a non-goal, in and of themselves.... That
is, if they want to exist that's great, and if someone wants to support
them that's great, but the primary target of the Mozilla Corporation, at
least, is end-users. I'm not sure what, if anything, the Foundation's
position on the matter is.

> Maybe something like the Ubuntu or Fedora/RedHat model with shortlived
> branches and only few long term support branches with security fixes only?

Historically, long term support "with security fixes only" requires a
_lot_ of resources. When we've tried to do it it has had a noticeable
negative effect on development.

That said, the long-lived Linux distro branches in fact maintain
long-lived Gecko/Firefox branches using their own resources. The setup
seems to be ok to me. If someone wanted to do something similar on
Windows for enterprise customers, they're welcome to, right?

-Boris

Robert O'Callahan

unread,
Jan 1, 2010, 2:51:22 PM1/1/10
to
On 2/01/10 7:20 AM, Boris Zbarsky wrote:
> That said, the long-lived Linux distro branches in fact maintain
> long-lived Gecko/Firefox branches using their own resources. The setup
> seems to be ok to me.

Historically they have actually done major version upgrades of Firefox
on those branches, though.

The nature of the Web doesn't really lend itself to long-lived stable
browser branches, IMHO. A lot of the security issues we discover in the
Web itself require proactive security measures such as UI and
architectural changes that one normally wouldn't apply to a "stable branch".

Rob

Simon Paquet

unread,
Jan 1, 2010, 5:10:39 PM1/1/10
to
Boris Zbarsky wrote on 01. Jan 2010:

>> Enterprise customer deployments?
>
> Last I checked, those were a non-goal, in and of themselves....
> That is, if they want to exist that's great, and if someone wants
> to support them that's great, but the primary target of the Mozilla
> Corporation, at least, is end-users. I'm not sure what, if anything,
> the Foundation's position on the matter is.

Well, if Firefox wants to maintain its growth vector, then sooner or
later (probably sooner) MoCo has to think of a strategy for the
enterprise market. The reality of having a 24%-32% marketshare worldwide
(based on the NetApplications or Statcounter numbers) is, that you
already have quite a few countries where your current marketshare is in
the 50+ bucket and without seriously tackling the enterprise market, it
will be hard to grow there in a significant way.

Simon

Uli Link

unread,
Jan 1, 2010, 5:37:01 PM1/1/10
to
Boris Zbarsky schrieb:

> Historically, long term support "with security fixes only" requires a
> _lot_ of resources. When we've tried to do it it has had a noticeable
> negative effect on development.

No doubt. I only know very few developers preferring maintainance work
over developing on the bleeding edge.

> That said, the long-lived Linux distro branches in fact maintain
> long-lived Gecko/Firefox branches using their own resources. The setup
> seems to be ok to me. If someone wanted to do something similar on
> Windows for enterprise customers, they're welcome to, right?

But their fixes won't land in CVS. Which relates to the time the modules
owners have for reviewing patches.
No structures for separating maintainance from development.
I guess the real problem is maintaining the infrastructer for QA.

--
ULi


chris hofmann

unread,
Jan 1, 2010, 5:44:38 PM1/1/10
to dev-pl...@lists.mozilla.org
I'm not sure there has ever been any offical position on "the
enterprise", or if there ever really needs to be.

What we can say is that Firefox growth in large organizations seems to
be tracking at about the same growth rate as what most would consider
"the consumer market". The growth seems to be coming by just trying to
focus on building software that makes indiduals more productive when
they use the web, and continue to focus on fast response to security
problems to keep possible vulnerabilities from becoming exploits running
in the wild.
https://wiki.mozilla.org/Deployment:Deploying_Firefox#Marketshare_in_the_Enterprise_and_Business
has some links the support the idea that market share growth in the
Enterprise is doing just fine. If anyone has spotted latest numbers
from Gartner/Forester or other surveys please update the wiki.

Some of the surveys indicate that about one-third of all software in the
Enterprise is not authorized or controlled by IT departments due to
increase sophistication of users, user desire to find tools that help
them be more productive at work, and understaffed IT departments that
can't keep up with demand of users within their business. Those numbers
would suggest there is still room for continued growth.

The strategy that got Firefox to +20% marketshare in the enterprise so
far ought to be contined. Focus on just making users more productive
using the web and adoption across all kinds of users will be just fine.

So called "conservative enterprise organizations" that do try to
exercise more controll and don't update OSes and Applications at
frequent rates are likely to still running old versions of NT and IE6.
They probably won't be interested in adopting Firefox no matter what the
pace of Major and Minor releases of Firefox is.

Faster moving large organizations are interested in CSP and other
security feature and will be trying to figure out ways to deploy them as
soon as we can deliver. We should really focus on this later group that
try to keep pace with advancement of browser technology.

-chofmann

Uli Link

unread,
Jan 1, 2010, 5:54:21 PM1/1/10
to
Robert O'Callahan schrieb:

> Historically they have actually done major version upgrades of Firefox
> on those branches, though.

Yes and they also had to fresh up GNOME2 stack to make this possible.

> The nature of the Web doesn't really lend itself to long-lived stable
> browser branches, IMHO. A lot of the security issues we discover in the
> Web itself require proactive security measures such as UI and
> architectural changes that one normally wouldn't apply to a "stable
> branch".

Two sides of the medal: the interactive multimedia stuff will broaden
possible future attack vectors, not relevant in a stable branch.

Long-lived is a relative term. 12 or 15 months is too less, even for
many non-geek end users. 36months is were enterprise usage can start.
As rough estimates. Maybe I've worked to much in vertical markets, were
customers want 10 years warranted support ;-)

--
ULi

Uli Link

unread,
Jan 1, 2010, 6:03:23 PM1/1/10
to
Simon Paquet schrieb:

> Well, if Firefox wants to maintain its growth vector, then sooner or
> later (probably sooner) MoCo has to think of a strategy for the
> enterprise market. The reality of having a 24%-32% marketshare worldwide
> (based on the NetApplications or Statcounter numbers) is, that you
> already have quite a few countries where your current marketshare is in
> the 50+ bucket and without seriously tackling the enterprise market, it
> will be hard to grow there in a significant way.

This end user market share urged most webmasters to support standard
HTML in addition to M$ HTML, even so far that M$ started to become more
standard conforming.
Next step can be urging SAP / M$ Dynamics / Oracle to fully support
Firefox as frontend GUI for their enterprise apps instead still often
requiring IE.

--
ULi

Uli Link

unread,
Jan 1, 2010, 6:19:40 PM1/1/10
to
chris hofmann schrieb:

> https://wiki.mozilla.org/Deployment:Deploying_Firefox#Marketshare_in_the_Enterprise_and_Business
> has some links the support the idea that market share growth in the
> Enterprise is doing just fine. If anyone has spotted latest numbers from
> Gartner/Forester or other surveys please update the wiki.

This growth may be made possible also by the long lifecycle of 2.0 and
3.0. This may become worse if significantly speeding up the schedule.

> So called "conservative enterprise organizations" that do try to
> exercise more controll and don't update OSes and Applications at
> frequent rates are likely to still running old versions of NT and IE6.
> They probably won't be interested in adopting Firefox no matter what the
> pace of Major and Minor releases of Firefox is.

Don't agree. many, many users are small or medium business. The big ones
usually have much more strictly managed desktops.
Even Cisco or SAP try to break into this market as growth vector.

--
ULi


Boris Zbarsky

unread,
Jan 1, 2010, 8:43:24 PM1/1/10
to
On 1/1/10 5:37 PM, Uli Link wrote:
> But their fixes won't land in CVS.

Why not? Linux distro maintenance fixes for the 1.8 branch landed in
mozilla.org CVS...

> Which relates to the time the modules owners have for reviewing patches.

Sure; there's always a cost here. I _wish_ I hadn't had to review any
of those 1.8 patches, but that's just life.

> No structures for separating maintainance from development.

Not sure what you mean.

> I guess the real problem is maintaining the infrastructer for QA.

No, the real problem is finite numbers of people who know the code well,
all of whom can be better occupied than maintaining years-old code that
very few actual users use.

-Boris

chris hofmann

unread,
Jan 1, 2010, 11:18:42 PM1/1/10
to dev-pl...@lists.mozilla.org
On 1/1/10 3:19 PM, Uli Link wrote:
> chris hofmann schrieb:
>
>> https://wiki.mozilla.org/Deployment:Deploying_Firefox#Marketshare_in_the_Enterprise_and_Business
>>
>> has some links the support the idea that market share growth in the
>> Enterprise is doing just fine. If anyone has spotted latest numbers from
>> Gartner/Forester or other surveys please update the wiki.
>
> This growth may be made possible also by the long lifecycle of 2.0 and
> 3.0. This may become worse if significantly speeding up the schedule.
>
We can all speculate on what might, or might have not have impact on the
growth, and what might slow or block growth in the future.

I'll submit the growth happened because we made a better browser.
I'll submit that if we continue to make a better browser the growth will
continue.
If we make missteps then the growth is uncertain for all kinds of users.

>> So called "conservative enterprise organizations" that do try to
>> exercise more controll and don't update OSes and Applications at
>> frequent rates are likely to still running old versions of NT and IE6.
>> They probably won't be interested in adopting Firefox no matter what the
>> pace of Major and Minor releases of Firefox is.
>
> Don't agree. many, many users are small or medium business. The big
> ones usually have much more strictly managed desktops.

Yeah, we know of small or medium businesses. We also know of large
fortune 500 businesses that have adopted Firefox. Some of these are
tightly controlled environments on Wall Street, and some are not so
tightly controlled.

I'm not sure if the size of the business is really the key. Its more
like there are fast moving companies that adopt technology that makes
there workers more secure and productive, and there are businesses that
move slower. The slower companies moved slower on adopting WiFi; they
moved slower on updating to *any* new browser technology; they are
moving slower on mobile technology adoption like the iphone.

Trying to target the businesses that move slower is difficult and lower
margin for Cisco, SAP, and any other business that focuses on large
institutions. They try to overcome these obstacles with large sales
and support forces and large marketing budgets. That's not the grass
roots and "bottom up" approach that has been successful for Firefox so
far for both consumer and business markets. Large sales, support and
marketing is also not the kind of strategy that is being pursued by
salesforce.com or other new technology companies that have tried to
enter the enterprise market in the past few years. The strategy used by
these new enterprise software providers is to get the customer to "sell
themselves" on the product, and adopt the software or service if they
find it useful. Realistically that is the only kind of strategy that
makes sense for us, and it turns out to have worked quite well for us
over the last 5 years.

I'll submit that the number of people in larger, and slower moving,
kinds of institutions are growing smaller; and that one-third of all
software that is not controlled by IT is actually growing. It will
continue to grow year over year. That means we still have at least a
few years of good growth before we hit 33% market share in the
enterprise, and maybe by then the number will be higher.


> Even Cisco or SAP try to break into this market as growth vector.
>

-chofmann

Philip Chee

unread,
Jan 1, 2010, 11:27:58 PM1/1/10
to
On Fri, 01 Jan 2010 20:43:24 -0500, Boris Zbarsky wrote:
> On 1/1/10 5:37 PM, Uli Link wrote:
>> But their fixes won't land in CVS.
>
> Why not? Linux distro maintenance fixes for the 1.8 branch landed in
> mozilla.org CVS...

Are they still landing in CVS? SeaMonkey 1.1 (Gecko 1.8) is still
currently supported. We've tried to contact the linux distro people to
ask if they plan to land any more security patches in order to decide
how much longer we can realistically support that branch. However all of
them seem to have disappeared for the end of year seasonal holidays
since the beginning of December.

Gervase Markham

unread,
Jan 2, 2010, 5:54:44 AM1/2/10
to
On 01/01/10 18:20, Boris Zbarsky wrote:
> Last I checked, those were a non-goal, in and of themselves.... That
> is, if they want to exist that's great, and if someone wants to support
> them that's great, but the primary target of the Mozilla Corporation, at
> least, is end-users. I'm not sure what, if anything, the Foundation's
> position on the matter is.

The Foundation's position (AIUI) is that Firefox product positioning
decisions are made by the Mozilla Corporation. :-)

Gerv

Uli Link

unread,
Jan 2, 2010, 6:48:45 AM1/2/10
to
Boris Zbarsky schrieb:

>> No structures for separating maintainance from development.
>
> Not sure what you mean.

Handover to a different person/team/maintainer.

Approving patches with minimal impact is a different skill from creative
developing of new functionality.

But my starting point was a much easier question:
- define the starting point: branching in Mercurial (or the golden
release date?)
- define the End of Maintenance date. For e.g. 36months after branching
- Release schedule: one branch per 12 months
==> 3 to 4 active branches.
- Shorten down to 9 months you have to add another active branche or the
shorten the lifetime for constant given resources.

All numbers are just for example.
No prophet needed for seeing the impact of speeding up the schedule for
given resources, maybe counted as number of tinderboxes.

From the users point of view a (halfways) predictive lifecycle is just
another product feature. Just like the colours of default theme or the
logo. Non-technical. High priority in the enterprise, low for home users.
I know the logos and look and feel, I can read about new features.
But schedule is a little vague ;-)
I wanted to add this aspect to the else technical discussion.

--
ULi

Uli Link

unread,
Jan 2, 2010, 7:01:51 AM1/2/10
to
Philip Chee schrieb:

> On Fri, 01 Jan 2010 20:43:24 -0500, Boris Zbarsky wrote:
>> On 1/1/10 5:37 PM, Uli Link wrote:
>>> But their fixes won't land in CVS.
>>
>> Why not? Linux distro maintenance fixes for the 1.8 branch landed in
>> mozilla.org CVS...
>
> Are they still landing in CVS? SeaMonkey 1.1 (Gecko 1.8) is still
> currently supported. We've tried to contact the linux distro people to
> ask if they plan to land any more security patches in order to decide
> how much longer we can realistically support that branch. However all of
> them seem to have disappeared for the end of year seasonal holidays
> since the beginning of December.

I see 3 checkins in December, not counting KaiRo's Seamonkey copyright
string 2010 bumping from the tinderbox page.

--
ULi

Boris Zbarsky

unread,
Jan 2, 2010, 10:36:59 AM1/2/10
to
On 1/2/10 6:48 AM, Uli Link wrote:
> Handover to a different person/team/maintainer.

We've certainly done effective handovers to a different set of patch
developers. However, there is no different set of people to do
effective review.

> Approving patches with minimal impact is a different skill from creative
> developing of new functionality.

I have yet to see a security fix with "minimal impact". They tend to be
changes to the most fragile code one can find, and have to be evaluated
_very_ carefully to make sure they actually fix the security bug and
don't break too much.

> - Release schedule: one branch per 12 months
> ==> 3 to 4 active branches.

We've tried having this many branches before. It's not really workable
unless we have a LOT more manpower than we have now. And I mean
manpower of the sort that can do the hardest parts of development (the
security fixes), not just manpower in general....

-Boris

Uli Link

unread,
Jan 2, 2010, 11:36:51 AM1/2/10
to
Boris Zbarsky schrieb:

>> Approving patches with minimal impact is a different skill from creative
>> developing of new functionality.
>
> I have yet to see a security fix with "minimal impact". They tend to be
> changes to the most fragile code one can find, and have to be evaluated
> _very_ carefully to make sure they actually fix the security bug and
> don't break too much.

Maybe because the patches are developed on trunk / with trunk in mind.
Maybe the code is so fragile because it had not had the time to mature
in a positive fashion.
Sorry for questions only ;-)
If I would know the answer, I would be at least as rich as Dagobert Duck.
It's only my impression following (sometimes feeling like being hunted)
the development since Firefox 1.0.x

>> - Release schedule: one branch per 12 months
>> ==> 3 to 4 active branches.
>
> We've tried having this many branches before. It's not really workable
> unless we have a LOT more manpower than we have now. And I mean manpower
> of the sort that can do the hardest parts of development (the security
> fixes), not just manpower in general....

No surprise. It's time-critical and confidential before disclosure. Such
workload is better done in small teams.
It only has to be clear that spinning the wheel faster will therefore
result in a even shorter lifecycle.

--
ULi

Boris Zbarsky

unread,
Jan 2, 2010, 12:31:31 PM1/2/10
to
On 1/2/10 11:36 AM, Uli Link wrote:
> Maybe because the patches are developed on trunk / with trunk in mind.

Not really, no.

> Maybe the code is so fragile because it had not had the time to mature
> in a positive fashion.

The oldest code is usually the most fragile, for what it's worth. And
it's usually that way because it was developed by a combination of
reverse-engineering IE (and to some extent Netscape 4) and security
patching at the same time. As a result, there is no clear behavior
spec, but changes from current behavior can easily break websites or
introduce security bugs in their own right.

> It only has to be clear that spinning the wheel faster will therefore
> result in a even shorter lifecycle.

I don't think that there are many users or web developers who would
object to a slower lifecycle for old browser versions, modulo extension
compatibility concerns...

-Boris

Uli Link

unread,
Jan 2, 2010, 1:58:31 PM1/2/10
to
Boris Zbarsky schrieb:

>> Maybe the code is so fragile because it had not had the time to mature
>> in a positive fashion.
>
> The oldest code is usually the most fragile, for what it's worth. And
> it's usually that way because it was developed by a combination of
> reverse-engineering IE (and to some extent Netscape 4) and security
> patching at the same time. As a result, there is no clear behavior spec,
> but changes from current behavior can easily break websites or introduce
> security bugs in their own right.

10 years + old code is NOT what I mean as "mature". For C++ 10 years ago
was a different language in real world. Especially the UNIX cfront C++
compilers were a nightmare, C programming wrapped into classes.
And Netscape 4 supported them all meaning at the very smallest common
denominator, yes there were binaries for Novell UnixWare 1.1 and
NCR/AT&T UNIX. Or M$VC++ 1.5 for Win16...
This legacy needs to be replaced, better before a decade is over.
This is not a matter of maintainance, a complete rewrite usually is much
cheaper.

>> It only has to be clear that spinning the wheel faster will therefore
>> result in a even shorter lifecycle.
>
> I don't think that there are many users or web developers who would
> object to a slower lifecycle for old browser versions, modulo extension
> compatibility concerns...

It's not for older browser versions, it's for freeing resources.

I totally aggree with letting the 1.8.1 branch die now. Also 1.9.0 can
go it's way.
The Linux distros which are based on 1.9.0 can easily adopt 1.9.1 or
1.9.2 (same runtime requirements).

But Seamonkey and Thunderbird have even recently kept up. So 1.9.1
should be kept alive for about 6 months after release of their next
major release, and not a few months before. Not because they wanted to
offend me but because of limited resources. They need carefull planning
were to spend their resources (1.9.2/1.9.3?)

Recent user expirience from real world:
It was hard to convince my wife updating her notebook from Seamonkey
1.1.18 to 2.0.1 after she saw and heard me hitting/fighting bug# 535528.
So a smooth migration/update path is existential for user's confidence.
You can replace this with an incompatible but loved extension or many
other reasons.

--
ULi


Mike Beltzner

unread,
Jan 2, 2010, 2:03:46 PM1/2/10
to ul.mc...@linkitup.de, dev-pl...@lists.mozilla.org
I think this discussion has meandered quite far off the topic of the
original request for input that Benjamin wrote.

If we want to discuss the various mechanisms and metrics for code quality
and maturity separately, I suggest a newsgroup other than dev.planning -
perhaps dev.platform?

cheers,
mike

--
ULi


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

Gen Kanai

unread,
Jan 2, 2010, 7:56:44 PM1/2/10
to Uli Link, dev-pl...@lists.mozilla.org
On 1/2/10 8:03 AM, Uli Link wrote:
> Oracle to fully support Firefox as frontend GUI for their enterprise
> apps instead still often requiring IE.

Which Oracle apps? Unbreakable Linux is Oracle's reference platform and
Firefox 3 and 3.5 have been certified for Oracle's e-Business Suite for
some time now.

http://blogs.oracle.com/stevenChan/2009/02/firefox_3_certified_with_e-business_suite.html
http://blogs.oracle.com/stevenChan/2009/09/firefox_35_ebs_certified.html

(Oracle's blog server seems to be down for me atm.)

Actively going after the "enterprise" market is a mirage that Mozilla
should actively avoid for all of the reasons that chofman and many, many
others have cited throughout the past 5 years of Firefox.

We are most successful when we make a great product for end users. Any
change of focus, certainly to the enterprise, is folly and would
certainly lead us away from the success Firefox enjoys today.

Message has been deleted

Boris Zbarsky

unread,
Jan 3, 2010, 6:54:19 PM1/3/10
to
On 1/3/10 5:48 PM, Simon Paquet wrote:
> For example, making Firefox more easily customizable and configurable for
> enterprise admins, would make Firefox much more accessible to millions of
> enterprise users

Sure; the question is what the opportunity cost is.

Or put another way, what other thing that's being worked on should be
dropped to do this?

-Boris

Axel Hecht

unread,
Jan 3, 2010, 9:05:51 PM1/3/10
to
On 03.01.10 23:48, Simon Paquet wrote:
> I agree that Mozilla should not sacrifice its values or its focus by
> going after enterprise users, but how does the exclusive focus on the
> end-user advance Mozilla's goal of an open web while a shared focus on
> end-users AND enterprise users does not?

>
> For example, making Firefox more easily customizable and configurable for
> enterprise admins, would make Firefox much more accessible to millions of
> enterprise users, who at the moment can't or don't know how to circumvent
> the policies on their enterprise desktop.
>

As chofmann pointed out, there are a fair number of enterprises that get
along with what Firefox is quite nicely.

I argue that enterprises that don't get along with that might want (and
might possibly deserve) a gecko-based browser, but they don't want
Firefox, as in, the user-empowering self-determined web experience. If
someone wants to play catch with sysops on where that browser experience
would be, fine, but I don't see ourselves bored enough for us to be that
one. "Us" in the sense of people working on the dito Firefox.

Axel

John J. Barton

unread,
Jan 3, 2010, 11:47:42 PM1/3/10
to
Axel Hecht wrote:
...

>
> I argue that enterprises that don't get along with that might want (and
> might possibly deserve) a gecko-based browser, but they don't want
> Firefox, as in, the user-empowering self-determined web experience. If

And what evidence do you have to support this demeaning argument?

> someone wants to play catch with sysops on where that browser experience
> would be, fine, but I don't see ourselves bored enough for us to be that
> one. "Us" in the sense of people working on the dito Firefox.

Those of "us" who work at enterprises don't think too much of all this
uninformed speculation.

At least at IBM we have many strong advocates for Firefox. The number
one reason Firefox has maintained a strong position is security. The
number one problem it has to overcome is the cost of browser-compatible
applications. All three primary competitors (IE, Java, and Flash) have
(or had) better application support; all have problems. Web 2.0 and
Firefox success have shifted the game in enterprises: it now looks like
the war is between Flash and Open Web.

Firefox can maintain enterprise market share through security,
performance, and application support. But the application developers
will determine the ultimate share. Unfortunately application developer
tools for open web remain behind.

Returning, for mike's sake, to the topic: IBM and our customers are all
moving to faster development cycles. That's why I urge Firefox team to
continue to lead in that direction.

jjb

Jean-Marc Desperrier

unread,
Jan 5, 2010, 6:33:27 AM1/5/10
to
Benjamin Smedberg wrote:
> Doing a release from mozilla-central/1.9.3 [...]
> [...] We would probably have to un-do changes
> that have already been made, such as the OJI plugin support removal

AFAIK, 3.6 will include OJI only on Mac, and only because Apple is late
to deliver a stable plugin2 release.

You are now of the opinion Apple is so late that you'll still need
plugin1 for Mac in the next release ?

Boris Zbarsky

unread,
Jan 5, 2010, 8:34:45 AM1/5/10
to
On 1/5/10 6:33 AM, Jean-Marc Desperrier wrote:
> You are now of the opinion Apple is so late that you'll still need
> plugin1 for Mac in the next release ?

If the "next release" is in March or so (which is the timeline we're
talking about for Lorentz here)? Probably, yes.

-Boris

Reply all
Reply to author
Forward
0 new messages