Thoughts on next release after Gecko 1.9 (a modest proposal)
Mike Schroepfer
We've had a number of good discussions in the recent Mozilla 2 meetings
about what we want to accomplish, and the work on ActionMonkey is
progressing well: http://wiki.mozilla.org/JavaScript:ActionMonkey.
I wanted to get some thoughts out on how to plan the next major Gecko
release. Some of this is re-hash from the Moz2 meetings - so bear with
me. Short version: I think we should work towards a Moz2 release as the
next release. We will also continue on a variety of lower-risk tasks
in parallel and aim one way or another to release another major version
~1 year after Firefox3.
Longer Explanation:
Definition: Moz2 means we can break API compatibility (hence
incrementing the major version number). That's it. It is implied that
some of the bigger changes below may either require us to break API
compat or may be substantially easier to do if we break compat.
Overall Goals (not in a particular order and stolen from Moz2 meeting):
* Improve developer productivity
* Performance
* Footprint
* Security
* Innovative web features
* Improved embedding and mobile support
* Building features in XUL needed by apps
* Better Support multicore systems
* Continuing to improve our UE
Goals of our Process:
We are building Mozilla for the long-run. Our primary goal is to push
the web forward. Firefox is the current instrument of that mission and
we should seek to maximize long-term development/product productivity.
We don't have any quarter-end, trade-show, or other artificial deadlines
which force us to make short term decisions that are detrimental to the
long-term. On the other hand, most of us are at Mozilla to ship
software that real people use. So I'd like us to ship as frequently as
possible but make decisions that ensure a long-term continuous stream of
high quality products from Mozilla. Shooting for the best product
delievery and engineering efficiency over a span of years is the goal
here.
Release Date:
Firefox 1.5 shipped just over 1 year from Firefox 1.0
Firefox 2.0 shipped about 11 months after Firefox 1.5
Firefox 3.0 (if ships in 1H08) will ship 17-30 months after Firefox 2.0
(but was under development for closer to 2-3 years)
Given our goals, past experience, it feels right to set a target for the
follow-on to Firefox 3 to ship about 1 year from Firefox 3. That should
give us enough time to make progress on the big long-term stuff but
isn't too long to compound risk. This is an interpolation between the
times of Firefox 3 and Firefox 2.
Tasks:
I'd like us to think of our tasks in three rough buckets. These buckets
are meant to categorize things mostly by level of risk to the overall
release. I've likely got the specific tasks in bucket B/C wrong (since
we haven't done this yet and this is a swag) but we can address later
here. Thinking of things in these buckets is more important this second
that the specific tasks.
A) Big, invasive, destabilizing changes. These are the sort of tasks
that don't respond well to compression (e.g. throwing more people at it)
and touch large pieces of the code and/or can destabilize other parts of
the development. These are the sort of changes that once landed into
the mainline development tree can become the long-pole for release and
are difficult to unwind. From the Moz2 meetings it appears the
following are in this category:
1) mmGC (including XPCOMGC) *already underway*
2) Exception support *already underway for tooling at least*
3) deCOM
4) Taramin JIT replacing SM *already underway*
5) Better threading support in the core layout engine
6) Centralized security checks
7) Removal of XPConnect
8) Major GFX pipeline changes
9) Protected mode
B) Medium sized, significant in impact changes. These are non-trival,
but better isolated. Easier to turn off or backout. Things such as:
1) XBL2
2) Frame construction cleanup
3) Inline re-flow
4) XUL box Model
5) Treaded parsing
6) Threaded image decoding
7) Fewer restarts (e.g. protected extension installs, etc)
8) Features needed for UE
9) UE improvements
C) Smaller, isolated changes. These are smaller, easy to turn off, or
don't impact other critical paths:
1) Worker threads
2) Video
3) Minor CSS improvements
4) Jail tag
5) SVG animation
6) SVG fonts
7) Tabs between windows
8) UE improvements
Plan:
We should pick 2-3 of the most important large tasks and prioritize them
as a #1 priority and resource them for success. This means as folks
peel off of Gecko 1.9 they should first try to help with these 2-3 large
tasks. Because we have a huge and awesome community, and because many
of these tasks don't parallelize well we'll have plenty of resources
left over to crank on items from buckets B and C.
We organize into teams so that each area has at least 2 folks working on
it (to prevent blocking on reviews, etc) and no more than 5-6 folks on
it (just too much communication overhead). Each feature team takes an
area from start to finish - e.g. don't start new tasks until this one is
done (to prevent end-game context switching and release risk). Ideally
no one person should be working on more than 1 (or maybe 2) features at
once (again to prevent context switching).
Each team (depending on size of task) will be working on a separate Hg
branch. We'll keep hg-central overall very high quality and
ready-to-ship. Merges to hg-central will not be allowed without
regression, performance, functionality parity. No more landing then
optimizing. We'll organize the tasks to prevent merge conflicts
wherever possible. This is why we can't undertake too many large items
at once. Easier Hg merging, the try server, and other tools will make
it much easier for folks to test out changes without first having to
merge them to mainline.
We ship alpha's from hg-central early on in the process on a 6-8 week
cadence. We'd strongly hope that 1-3 of the big (A) tasks is ready for
ship during the schedule. However, since we are working on lots of
smaller stuff in parallel if the big stuff takes longer than expected we
still have a stable base and a set of improvements to go into a release.
This gives us a couple of things:
a) It ensures that the big long-pole items of high impact are never
starved and are delivered as soon as possible
b) We don't take on *too* many of them at once and have to deal with
with challenges of compound regressions, performance issues, etc.
c) Gives us the ability to ship more easily if some of the big tasks
take too long
d) Tries to reduce the context-switch overhead that was hard on many
folks during the Firefox 3 release
e) The constant quality of the mainline makes it easier to isolate
changes, regressions,and be ready to ship.
So in short I think we need to courage to take on a few big tasks and
resource them for success, and the wisdom to not block all development
behind these tasks.
Thoughts? There are obviously many many details to nail down in terms
of prioritizing and ordering tasks, etc. and that will take some time.
But, I'd love to enter 2008 with a rough agreement at least on the 1.9.1
vs Moz2 issue.
Best,
Schrep
stu...@gmail.com
> A) Big, invasive, destabilizing changes. These are the sort of tasks
If it is something like using OpenGL/Direct3d it should probably be
under bucket B.
> C) Smaller, isolated changes. These are smaller, easy to turn off, or
> 5) SVG animation
> 6) SVG fonts
These are probably both more medium sized.
The rest of this sounds pretty good.
John J. Barton
> Thoughts? There are obviously many many details to nail down in terms
> of prioritizing and ordering tasks, etc. and that will take some time.
I think it would be very useful to re-organize your list to put the
changes you list under each goal, being ruthless in placing items only
under their primary goal. Short lists under major goals may need
attention. For example, my favorite, Developer productivity seems
slighted ;-).
> But, I'd love to enter 2008 with a rough agreement at least on the 1.9.1
> vs Moz2 issue.
Making this decision now may lock you in to risks that a few more months
may clarify. In particular, defining Moz2 as "FF3 + 1yr" OR as a certain
list of features may be more prudent than AND, software being what it is.
John.
Mike Schroepfer
>
> I think it would be very useful to re-organize your list to put the
> changes you list under each goal, being ruthless in placing items only
> under their primary goal. Short lists under major goals may need
Good suggestion. I'm worried that too many tasks go under multiple
categories (.e.g mmGC...)
> attention. For example, my favorite, Developer productivity seems
> slighted ;-).
mmGC, Exceptions, deCOM are all squarely aimed at this (well and perf,
footprint, security, but that's point #1 :-) ). Is there some stuff we
are missing? Probably lots of build config stuff (e.g. make Win32 no-op
builds not take 20 minutes :-P).
>
>> But, I'd love to enter 2008 with a rough agreement at least on the
>> 1.9.1 vs Moz2 issue.
>
> Making this decision now may lock you in to risks that a few more months
> may clarify. In particular, defining Moz2 as "FF3 + 1yr" OR as a certain
> list of features may be more prudent than AND, software being what it is.
Yep. Locking Scope + Time + Resources = failed project
(http://www.ambysoft.com/essays/brokenTriangle.html).
We have primary control over Time and Scope. I'm proposing that we fix
Time (~1 year) with some slush. Many, as you point out, of the scope
issues we won't know until we get further into them. This is why I'm
proposing we invest in a small portfolio of big/medium/small stuff.
Axel Hecht
I guess I'd throw localization infrastructure changes (read, l20n) in
this one.
I think that I can think in these buckets allright, I miss JS2, though.
Not so much in terms of "will it happen or not" but more in the sense of
"can I make my task depend on it?". To some extent, js2 and l20n might
be similar, as it's not too bad to limit their lines-of-code impact, or
to do that incrementally, but that they come with a learning curve
throughout the project. Or, if JIT makes central, I know that a
js-implemented feature or rewrite can be really measured for
performance, but JS2 completeness would say when I'm done with coding.
Axel
Benjamin Smedberg
> A) Big, invasive, destabilizing changes. These are the sort of tasks
> 7) Removal of XPConnect
I wouldn't call this "removal" but rather "fast-path DOM"... and I don't
think it's a bucket-A item. I think it could implemented as a much smaller
bucket-B item once the actionmonkey (tamarin JIT) stuff is landed.
> B) Medium sized, significant in impact changes. These are non-trival,
> but better isolated. Easier to turn off or backout. Things such as:
> 1) XBL2
This is tricky: we could either
* implements XBL2 and keep mozilla-XBL -- this is safe and in bucket two,
but has the problem that we're carrying around two significant
infrastructures that will interact poorly
* replace mozilla-XBL with XBL2 -- this is probably much easier to implement
correctly and quickly, but it involves rewriting our existing mozilla-XBL
bindings in XBL2. In some cases we can come up with automatic
transformations, but it will still be a pretty huge change that really
should be in bucket A above.
> Each team (depending on size of task) will be working on a separate Hg
> branch. We'll keep hg-central overall very high quality and
Note that several of these tasks have dependencies on eachother: XPCOMGC
depends on AM stage 1 and stage 2. Exception support depends on XPCOMGC.
> at once. Easier Hg merging, the try server, and other tools will make
> it much easier for folks to test out changes without first having to
> merge them to mainline.
>
> We ship alpha's from hg-central early on in the process on a 6-8 week
> cadence. We'd strongly hope that 1-3 of the big (A) tasks is ready for
> ship during the schedule. However, since we are working on lots of
> smaller stuff in parallel if the big stuff takes longer than expected we
> still have a stable base and a set of improvements to go into a release.
A critical piece of this plan that I think we need to nail is directing our
community of nightly testers. It's possible of course to simply have nightly
testers on mozilla-central at all times, but I don't think this provides
maximum leverage:
* Testers may want to actively follow one of the feature branches: e.g. the
UE team will have experiments and ask for testing of those before they hit
mozilla-central... an XBL2 branch will want testing from extension authors
and interested developers before it is merged to mozilla-central.
* We don't want to orphan a nightly tester: if they have been testing a
nightly from the UE branch, we'd like to keep them up to date nightly. If
the UE branch stops being developed, we want to repatriate that user to
mozilla-central
I think we can accomplish this through the update system and major update
offers:
+-------------------------------+
| Minefield Update |
| An update is available. You are currently using
| the Minefield stable nightly builds. We are looking for
| testers of the user experience branch. This branch contains
| experiments in the user interface design of Firefox. Would you like to
| update to the UE branch? |
| [ Update ] [ No thanks ] |
+-------------------------------+
Finally, I think that it may make sense to do an alpha every 4 weeks. I know
that mconnor has been planning a monthly cadence for new UE features, and
with an always-stable mozilla-central and release automation, I think we can
schedule the alphas more frequently than we have. But I think we should make
sure that we get automatic updates from alpha->alpha so we don't leave
people stranded.
--BDS
Adam Kowalczyk
> Each team (depending on size of task) will be working on a separate Hg
> branch. We'll keep hg-central overall very high quality and
> ready-to-ship. Merges to hg-central will not be allowed without
> regression, performance, functionality parity. No more landing then
> optimizing. We'll organize the tasks to prevent merge conflicts
> wherever possible. This is why we can't undertake too many large items
> at once. Easier Hg merging, the try server, and other tools will make
> it much easier for folks to test out changes without first having to
> merge them to mainline.
While more decentralized development is certainly favorable from the
developers' perspective, I think that we need to figure out how to make
it work for our testing community. Right now there are unified nightlies
which contain all the checkins. This will no longer be the case when
there are multiple branches, which aren't merged back to hg-central
until the work is completed. Nightlies built from hg-central will not
include large chunks of changes which need testing.
As you describe, high quality and stability of the trunk is to be
ensured by fact, that major architectural changes won't be merged until
they meet the desired quality criteria. Yet, if these branches are
tested only by a relatively small number of involved developers, then
the quality isn't going to be verified as well as it would be by
thousands of community testers. This is going to detract from the
quality gains. Even though I am convinced that the balance is still
going to be positive, we should give some thought to this issue.
How do we enable and encourage testing of the branches?
Because back-end changes aren't visible to users and not many people get
excited by the fact that their Firefox now uses garbage collection
instead of reference counting, relatively few folks would be interested
in dog fooding the branch builds. Putting out separate nightlies for
different branches is probably out of the question. It would be
impossible from the build system perspective to provide automatic
updates and multiple nightlies would be too confusing for casual
testers. Not to mention that it would impose additional burden on
developers to make sure that the branches compile and are dog-foodable
day by day.
The least that should be done then, is to make fairly regular builds
available to the public and advertise them on QMO.
Maybe these problems are inherent to branched development, maybe it's
just an unavoidable trade-off. But it would be prudent and welcomed by
the testing community if we worked out some kind of strategy.
- Adam
Martijn
> * replace mozilla-XBL with XBL2 -- this is probably much easier to implement
> correctly and quickly, but it involves rewriting our existing mozilla-XBL
> bindings in XBL2. In some cases we can come up with automatic
> transformations, but it will still be a pretty huge change that really
> should be in bucket A above.
Removal of current mozilla-XBL sounds like a very bad idea to me.
Regards,
Martijn
Benjamin Smedberg
Could you be more specific? Are you concerned about
1) breaking the web
2) destabilizing Firefox itself
3) harming XUL application developers who use XBL?
Of these concerns, I think 2) is most valid. We've said for a long time that
XBL is not a finished technology, and we've changed it many times already in
subtle and incompatible ways. Especially if we can provide a simple script
(XSLT) to convert simple mozXBL -> XBL2 I think that is sufficient.
--BDS
Dan Mosedale
>
> This is tricky: we could either
>
> * implements XBL2 and keep mozilla-XBL -- this is safe and in bucket two,
> but has the problem that we're carrying around two significant
> infrastructures that will interact poorly
>
> * replace mozilla-XBL with XBL2 -- this is probably much easier to implement
> correctly and quickly, but it involves rewriting our existing mozilla-XBL
> bindings in XBL2. In some cases we can come up with automatic
> transformations, but it will still be a pretty huge change that really
> should be in bucket A above.
It's not clear to me why this is an either/or proposition. Wouldn't the
easiest thing to do be to implement XBL2 and carry mozilla-XBL as long
as we need to until we're ready to do the rewrite/jettison step?
Dan
Sergey Yanovich
> Mike Schroepfer wrote:
>> Each team (depending on size of task) will be working on a separate Hg
>> branch. We'll keep hg-central overall very high quality and
>
> Note that several of these tasks have dependencies on eachother: XPCOMGC
> depends on AM stage 1 and stage 2. Exception support depends on XPCOMGC.
>
>> at once. Easier Hg merging, the try server, and other tools will make
>> it much easier for folks to test out changes without first having to
>> merge them to mainline.
Taking a closer look, everyone would agree, that usage of a DVCS, by
itself, is not making merging even a little bit easier. Such a system
"just" provides the capability to employ the development process, that
facilitates merging or even makes it seamless.
Linux kernel is a DVCS production use example closest to Mozilla in
size, success and sophistication. Long ago they abandoned CVS in favor
of first BitKeeper, and now git. Borrowing a few tricks from them
shouldn't hurt at all ;)
This topic has recently been discussed in m.d.platform "Mozilla 2
checkin patterns" thread: http://tinyurl.com/yp4ccn
The key concept is "subsystem" trees. All development happens there. The
trees are rebased over the "stable" release branch early and often.
Rebasing is essentially the old proven patch queue approach. BTW,
Mozilla2 team is using just the same technique. And it is a matter of
taste, which solution to use for that: 'quilt', 'hg mq', 'hg transplant'
or 'git rebase'.
>> We ship alpha's from hg-central early on in the process on a 6-8 week
>> cadence. We'd strongly hope that 1-3 of the big (A) tasks is ready for
>> ship during the schedule. However, since we are working on lots of
>> smaller stuff in parallel if the big stuff takes longer than expected we
>> still have a stable base and a set of improvements to go into a release.
>
> A critical piece of this plan that I think we need to nail is directing our
> community of nightly testers. It's possible of course to simply have nightly
> testers on mozilla-central at all times, but I don't think this provides
> maximum leverage:
>
> * Testers may want to actively follow one of the feature branches: e.g. the
> UE team will have experiments and ask for testing of those before they hit
> mozilla-central... an XBL2 branch will want testing from extension authors
> and interested developers before it is merged to mozilla-central.
>
> * We don't want to orphan a nightly tester: if they have been testing a
> nightly from the UE branch, we'd like to keep them up to date nightly. If
> the UE branch stops being developed, we want to repatriate that user to
> mozilla-central
>
> I think we can accomplish this through the update system and major update
> offers:
Automated updates of nightlies with variable changesets to test will
work! It is fairly easier to implement that an alternative, which is to
have a second branch for integration in addition to the release one.
The latter has some advantages like:
* all tester have the same executable, so less information from users is
required to identify the build that has a particular problem;
* all tester try all new features at the same time;
* it fares well with "stupid" infrastructure like ftp://, which is easy
to maintain.
But:
* with some automation, it shouldn't be difficult to determine exact
build in the former solution as well;
* given enough of testers, all branches will receive adequate attention.
In addition, it will be possible to establish testing priorities;
* once the above is true, locating the problem will be much-much easier
(changes in one module v. changes in all modules);
* last, but not least, dirty preliminary merging work will be avoidable.
Not only -mm kernel tree is unstable, but it also requires permanent
reconciliations between subsystems. And it is a huge diff against
release tree (last it was over 30 Mbs or more than 10%).
--
Sergey Yanovich
Boris Zbarsky
> It's not clear to me why this is an either/or proposition. Wouldn't the
> easiest thing to do be to implement XBL2 and carry mozilla-XBL as long
> as we need to until we're ready to do the rewrite/jettison step?
In some ways this may be more difficult than just implementing XBL2, at
least on the layout end. That is, making all the various parts of
layout/content that have to play nice with both moz-XBL and XBL2 is
likely to be a huge, fragile, crash-prone pain.
-Boris
Benjamin Smedberg
> Automated updates of nightlies with variable changesets to test will
> work! It is fairly easier to implement that an alternative, which is to
> have a second branch for integration in addition to the release one.
I'm sorry, I can't understand this paragraph. In the automatic update system
you can have multiple "update channels", so it's possible to associate an
update channel with "mozilla-central" and a different update channel with
"the UE subsystem branch".
--BDS
Sergey Yanovich
By variable changeset I mean that different tester may receive different
binaries via the same "update channel". Which particular binary to
supply is to be decided on each request. There may be different
strategies like, f.e.:
* XPCOMGC - 30%;
* Tamarin JIT - 20%;
* ...
* Worker threads - 5%.
The next day, priorities may change, and tester will receive next-day's
nightlies in different proportions.
Benjamin Smedberg
> By variable changeset I mean that different tester may receive different
> binaries via the same "update channel". Which particular binary to
> supply is to be decided on each request. There may be different
> strategies like, f.e.:
> * XPCOMGC - 30%;
> * Tamarin JIT - 20%;
> * ...
> * Worker threads - 5%.
>
>
> The next day, priorities may change, and tester will receive next-day's
> nightlies in different proportions.
This doesn't sound like a good idea to me: if one day you're running new UI
on the UE branch and the next day it's gone, I think that's likely to drive
testers away. And some testers may want to be involved in particular projects.
--BDS
Mike Schroepfer
> just an unavoidable trade-off. But it would be prudent and welcomed by
> the testing community if we worked out some kind of strategy.
>
Yes splitting our testing community to focus on multiple branches at
once is a difficult problem. We've done this before by producing 1-off
builds and asking people to download (e.g.
http://weblogs.mozillazine.org/josh/archives/2005/07/intel_mac_build.html).
As you and others mention we can use automated updates with either
explicit choices or sampling amounts builds to spread out the testing
amongst multiple branches in parallel. However, I think there is a
natural limit to how many major branches of development can happen
concurrently from a merging and testing perspective. This is why I
think we need to limit the number of CatA and CatB tasks we take on at
once. The hope is that some CatB and most CatC tasks can do just fine
with isolated testing and automated testing before they get merged into
the integration branch.
So I think we can do more parallel development than we have recently,
but we need to be very realistic about the costs and the limits of how
much we can do at once.
Mike Schroepfer
> Mike Schroepfer wrote:
>
>> A) Big, invasive, destabilizing changes. These are the sort of tasks
>
>> 7) Removal of XPConnect
>
> I wouldn't call this "removal" but rather "fast-path DOM"... and I don't
> think it's a bucket-A item. I think it could implemented as a much smaller
> bucket-B item once the actionmonkey (tamarin JIT) stuff is landed.
>
Ok. super-helpful. I think I'll take a second pass through the details
of the buckets and update once we've consolidated feedback.
>> Each team (depending on size of task) will be working on a separate Hg
>> branch. We'll keep hg-central overall very high quality and
>
> Note that several of these tasks have dependencies on eachother: XPCOMGC
> depends on AM stage 1 and stage 2. Exception support depends on XPCOMGC.
Yep. So we can't do these in parallel and need to make sure we really
really finish the first task before we move onto the next one. I think
the big question will be should we stop at XPCOMGC for this release or
continue on to exceptions...
> A critical piece of this plan that I think we need to nail is directing our
> community of nightly testers. It's possible of course to simply have nightly
> testers on mozilla-central at all times, but I don't think this provides
> maximum leverage:
>
> * Testers may want to actively follow one of the feature branches: e.g. the
> UE team will have experiments and ask for testing of those before they hit
> mozilla-central... an XBL2 branch will want testing from extension authors
> and interested developers before it is merged to mozilla-central.
>
> * We don't want to orphan a nightly tester: if they have been testing a
> nightly from the UE branch, we'd like to keep them up to date nightly. If
> the UE branch stops being developed, we want to repatriate that user to
> mozilla-central
>
> I think we can accomplish this through the update system and major update
> offers:
>
> +-------------------------------+
> | Minefield Update |
> | An update is available. You are currently using
> | the Minefield stable nightly builds. We are looking for
> | testers of the user experience branch. This branch contains
> | experiments in the user interface design of Firefox. Would you like to
> | update to the UE branch? |
> | [ Update ] [ No thanks ] |
> +-------------------------------+
Yep - spreading out or testing community is a pretty critical part of
this and should be done with care. As I said in a later post I think we
can do more than we are now through techniques as you suggest, but we
should be careful not to run too many things in parallel.
>
> Finally, I think that it may make sense to do an alpha every 4 weeks. I know
> that mconnor has been planning a monthly cadence for new UE features, and
> with an always-stable mozilla-central and release automation, I think we can
> schedule the alphas more frequently than we have. But I think we should make
> sure that we get automatic updates from alpha->alpha so we don't leave
> people stranded.
I'm happy run at whatever cadence works best for folks. 4 weeks is just
fine. I do think with release automation we can do a better job of
alpha->alpha updates..
Robert O'Callahan
> Mike Schroepfer wrote:
> > B) Medium sized, significant in impact changes. These are non-trival,
> > but better isolated. Easier to turn off or backout. Things such as:
> > 1) XBL2
>
> This is tricky: we could either
>
> * implements XBL2 and keep mozilla-XBL -- this is safe and in bucket two,
> but has the problem that we're carrying around two significant
> infrastructures that will interact poorly
>
> * replace mozilla-XBL with XBL2 -- this is probably much easier to implement
> correctly and quickly, but it involves rewriting our existing mozilla-XBL
> bindings in XBL2. In some cases we can come up with automatic
> transformations, but it will still be a pretty huge change that really
> should be in bucket A above.
I was thinking that too. "Implement XBL2 and keep mozilla-XBL" would
probably have so many strange interactions that it would be a bucket-A
item anyway. (I prefer the "replace" approach.)
Rob
Robert O'Callahan
> It's not clear to me why this is an either/or proposition. Wouldn't the
> easiest thing to do be to implement XBL2 and carry mozilla-XBL as long
> as we need to until we're ready to do the rewrite/jettison step?
As Boris said: no.
What we might be able to do is to retain support for some subset of
XBL1 *syntax* implemented using corresponding XBL2 features, to
provide some level of ongoing XBL1 compatibility.
Rob
Robert O'Callahan
> Each team (depending on size of task) will be working on a separate Hg
> branch. We'll keep hg-central overall very high quality and
> ready-to-ship. Merges to hg-central will not be allowed without
> regression, performance, functionality parity. No more landing then
> optimizing. We'll organize the tasks to prevent merge conflicts
> wherever possible. This is why we can't undertake too many large items
> at once. Easier Hg merging, the try server, and other tools will make
> it much easier for folks to test out changes without first having to
> merge them to mainline.
Let me argue that most C-bucket and some B-bucket items should
actually be developed in hg-central or at least be pushed there on a
regular basis. Features like <video> that aren't currently used
anywhere have a very small chance of causing trunk regressions. If we
want to ship and the feature isn't ready we can disable it trivially.
Having these features in hg-central will reduce testing and merging
costs. I think it matters a great deal that we can tell people
"download this build and play all these new cool features we're
working on".
Rob
Sergey Yanovich
That is all true.
> +-------------------------------+
> | Minefield Update |
> | An update is available. You are currently using
> | the Minefield stable nightly builds. We are looking for
> | testers of the user experience branch. This branch contains
> | experiments in the user interface design of Firefox. Would you like to
> | update to the UE branch? |
> | [ Update ] [ No thanks ] |
> +-------------------------------+
So the only option here is to ask users to switch "update channels", and
hope that each branch will sign up enough volunteers.
In this case, it still may be a good idea to have -mm kernel tree
equivalent, which will allow for a single nightly.
Robert O'Callahan
> I think it matters a great deal that we can tell people
> "download this build and play all these new cool features we're
> working on".
Also, the synergy between features is often the spark that takes a
demo from "cool" to "jaw-dropping". (HTML and canvas3d and SVG and
<video> whoooohoo!) One of the strengths of the Web platform over
proprietary plugins is that the Web is better for mixing up different
kinds of content. (Web content can contain any other kind of content;
Flash content can only contain Flash.) It's nice to be able to show
this without having to merge half a dozen branches.
Rob
Robert O'Callahan
> Yep. Locking Scope + Time + Resources = failed project
> (http://www.ambysoft.com/essays/brokenTriangle.html).
>
> We have primary control over Time and Scope. I'm proposing that we fix
> Time (~1 year) with some slush. Many, as you point out, of the scope
> issues we won't know until we get further into them. This is why I'm
> proposing we invest in a small portfolio of big/medium/small stuff.
IMHO the naming should depend on the scope. It doesn't make sense to
break compatibility in the next release unless the big changes that
demand compatibility-breakage are in that release. Therefore if those
changes don't make the next release, we should not be breaking
compatibility and we should not call it Mozilla2.
I would also argue that if that happens, we should ensure the next
release does not contain major Web-compatiblity-affecting changes, so
we could call it 1.9.1 with a straight face.
I would also argue that if it becomes apparent that "long pole" A-list
items aren't going to make the next release, we should try to
recognize that early and remove them from the blocking list, and be
ready to ship earlier than a year if that list becomes empty. I
suppose Firefox front-end scheduling may not permit this.
Rob
John J Barton
>
>> attention. For example, my favorite, Developer productivity seems
>> slighted ;-).
>
> mmGC, Exceptions, deCOM are all squarely aimed at this (well and perf,
> footprint, security, but that's point #1 :-) ). Is there some stuff we
> are missing? Probably lots of build config stuff (e.g. make Win32 no-op
> builds not take 20 minutes :-P).
I suppose it depends on which developers you are targeting. From what I
understand of these, they will primarily help non-Javascript developers
who are integrating multiple mozilla C++ components. They will also help
new C++ component developers as the component-infrastructure cruft will
be less. These are important and valuable improvements. But I don't see
much on the list for C++ component maintainers or Javascript (web or
XUL) developers. I imagine that these folks are the bulk of the Mozilla
dev community?
Anyway the feature list derives from personal interests of the
developers, so it probably does not make sense to over analyze it.
John.
bre...@mozilla.org
> Let me argue that most C-bucket and some B-bucket items should
> actually be developed in hg-central or at least be pushed there on a
> regular basis. Features like <video> that aren't currently used
> anywhere have a very small chance of causing trunk regressions. If we
> want to ship and the feature isn't ready we can disable it trivially.
> Having these features in hg-central will reduce testing and merging
> costs. I think it matters a great deal that we can tell people
> "download this build and play all these new cool features we're
> working on".
This is right on, and indeed for ActionMonkey we have often merged low-
risk changes toward more central repos (even into cvs.m.o) to reduce
merge headaches and get the goodness out early and often.
We should resist the DVCS temptation to fork unduly, even if only as a
calculated temporary condition.
/be
Mike Shaver
> Mike Schroepfer wrote:
> >
> >> attention. For example, my favorite, Developer productivity seems
> >> slighted ;-).
> >
> > mmGC, Exceptions, deCOM are all squarely aimed at this (well and perf,
> > footprint, security, but that's point #1 :-) ). Is there some stuff we
> > are missing? Probably lots of build config stuff (e.g. make Win32 no-op
> > builds not take 20 minutes :-P).
>
> I suppose it depends on which developers you are targeting. From what I
> understand of these, they will primarily help non-Javascript developers
> who are integrating multiple mozilla C++ components. They will also help
> new C++ component developers as the component-infrastructure cruft will
> be less. These are important and valuable improvements. But I don't see
> much on the list for C++ component maintainers or Javascript (web or
> XUL) developers. I imagine that these folks are the bulk of the Mozilla
> dev community?
Hey, those devs are my peeps!
I think there are a ton of things in this list which will help C++
component maintainers and "markup" (JS/XUL/HTML/etc.) developers from
both sides of the chrome/content fence.
MMgc and exceptions will make the memory management and error-handling
aspects of implementing XPCOM components much, much less burdensome,
and the tools we are building to facilitate the conversions will help
out-of-tree component developers as they help us. Improved threading
capabilities in the core of layout will help people who are doing work
on background threads
The Tamarin JIT, DOM fast-pathing, centralization of security,
exception support, unified MMgc and worker threads help everyone who
writes JS, for content or the app/extensions. A lot. You will feel
the earth move beneath you.
SVG improvements, the XUL box model, video, parallelization of image
decoding and parsing, CSS improvements, the GFX-layer improvements all
help people building interfaces on the web, in extension, or in the
core of the product.
If you have specific needs that aren't on that list, this is a great
time to make the case for them. I'm sure that the people working on
Tamarin integration would love your feedback on the debugging APIs as
they evolve, as but one example.
> Anyway the feature list derives from personal interests of the
> developers, so it probably does not make sense to over analyze it.
No, I don't think that's fair -- the feature list derives from the
collective estimation of the return on the investments outlined, their
dependencies, and their impact on schedule. I don't think the people
who would be doing XBL2 use it that much, for example!
"Over"-analysis is excessive, tautologically, but thorough analysis of
the tradeoffs and prioritizations of these items is exactly what this
thread is for.
Mike
John J Barton
Yes, I as said, this is good.
>
> The Tamarin JIT, DOM fast-pathing, centralization of security,
> exception support, unified MMgc and worker threads help everyone who
> writes JS, for content or the app/extensions. A lot. You will feel
> the earth move beneath you.
I guess I need to know more. These are great things, but they help
developers in the same way that faster CPUs and cheaper displays help.
>
> SVG improvements, the XUL box model, video, parallelization of image
> decoding and parsing, CSS improvements, the GFX-layer improvements all
> help people building interfaces on the web, in extension, or in the
> core of the product.
Again great stuff. Like multicore, bluetooth, 32 bit color.
>
> If you have specific needs that aren't on that list, this is a great
> time to make the case for them. I'm sure that the people working on
> Tamarin integration would love your feedback on the debugging APIs as
> they evolve, as but one example.
I think that from the average developers point of view the road blocks
to faster development are things like how fast can I go from code change
to code-test, and from there to commit, and from there to release. And
in reverse, how fast can I go from bug report to code change. For new
code, the biggest barrier is platform complexity; for new developers the
dev environment setup is a huge barrier. This would argue for better
support of dependency analysis, incremental composition of modules, even
deeper integration with online systems like breakpad, bugzilla, and mdc,
as well as better dev tools tailored for mozilla rather than windows or
linux.
John.
Schrep
> Let me argue that most C-bucket and some B-bucket items should
> actually be developed in hg-central or at least be pushed there on a
> regular basis. Features like <video> that aren't currently used
> anywhere have a very small chance of causing trunk regressions. If we
> want to ship and the feature isn't ready we can disable it trivially.
> Having these features in hg-central will reduce testing and merging
> costs. I think it matters a great deal that we can tell people
> "download this build and play all these new cool features we're
> working on".
>
Yep I'd in general agree. As long as they don't destabilize or affect
performance (video is very unlikely to do either) than they can be
merged early and often.
Schrep
Yep - I think all of that makes sense. I'd suggest the final call on
this around May 08. If we want to get a release out in a year we
should try and get to Beta 1 around October, we can start Alpha 1 in
April. So this would be Alpha2 - leaves us 4 more Alphas do we major
work in time for Beta1.
Schrep
err s/affect/effect :-)
Schrep
wrote:
> On Wed, 19 Dec 2007 01:14:26 UTC, Mike Schroepfer wrote:
> > But, I'd love to enter 2008 with a rough agreement at least on the 1.9.1
> > vs Moz2 issue.
>
> 1.9.1 wasn't really mentioned in your post or I missed it. Do you
> envision the (A) group of tasks to be 2.0 only, and (C) and some of (B)
> to go into 1.9.1 as well? 1.9.1 will still be CVS based, right?
I'm saying no matter what we move to Hg and work on a collection of
A,B, and C tasks. By around April/May we make the final judgment on
whether the A stuff is far enough along.
Schrep
> On Dec 18, 5:14 pm, Mike Schroepfer <sch...@mozilla.com> wrote:> A) Big, invasive, destabilizing changes. These are the sort of tasks
> > 8) Major GFX pipeline changes
>
> Not sure what this is -- probably shouldn't be under this category.
> If it is something like using OpenGL/Direct3d it should probably be
> under bucket B.
>
Hrm. Was thinking like Roc's compositer stuff. Roc said on IRC this
is B. so it is!
> > C) Smaller, isolated changes. These are smaller, easy to turn off, or
> > 5) SVG animation
> > 6) SVG fonts
>
> These are probably both more medium sized.
Sweet. Thanks.
>
> The rest of this sounds pretty good.
smaug
> 1) mmGC (including XPCOMGC) *already underway*
> 2) Exception support *already underway for tooling at least*
> 3) deCOM
> 4) Taramin JIT replacing SM *already underway*
> 5) Better threading support in the core layout engine
> 6) Centralized security checks
> 7) Removal of XPConnect
> 8) Major GFX pipeline changes
>
> B) Medium sized, significant in impact changes. These are non-trival,
> but better isolated. Easier to turn off or backout. Things such as:
> 1) XBL2
> 3) Inline re-flow
> 4) XUL box Model
> 5) Treaded parsing
> 6) Threaded image decoding
> 7) Fewer restarts (e.g. protected extension installs, etc)
> 8) Features needed for UE
> 9) UE improvements
>
> C) Smaller, isolated changes. These are smaller, easy to turn off, or
> 1) Worker threads
> 2) Video
> 3) Minor CSS improvements
> 4) Jail tag
> 5) SVG animation
> 6) SVG fonts
> 8) UE improvements
>
One possible addition to the list: "do something to the event handling".
It may contain DOMEvent/nsEvent merge or split,
moving event handling out of nsIFrames, cleaning up EventStateManager.
(EventListenerManager got mainly cleaned up already for 1.9)
Might be in B or C category, though it touches lots of code. But it is
more clean-up like thing than a new feature, and might be even less
riskier than the dom-event-dispatch-rewrite that was done for 1.9.
-Olli
Colin Barrett
> I think that from the average developers point of view the road blocks
> to faster development are things like how fast can I go from code change
> to code-test, and from there to commit, and from there to release. And
> in reverse, how fast can I go from bug report to code change. For new
> code, the biggest barrier is platform complexity; for new developers the
> dev environment setup is a huge barrier. This would argue for better
> support of dependency analysis, incremental composition of modules, even
> deeper integration with online systems like breakpad, bugzilla, and mdc,
> as well as better dev tools tailored for mozilla rather than windows or
> linux.
I think you vastly underestimate how much things like garbage collection
will help. No more time spent thinking about memory management.
Exceptions mean you don't need to worry about formating your code so
doing all the required nsresult error checking doesn't result in huge
numbers of indents.
A lot of these things will make writing Mozilla code so much smoother
and cleaner and /more understandable/. If you can hold more of the
codebase in your head at once, you don't have to hit mxr and re-page all
of that knowledge back in.
Why am I able to write python or JS much quicker than mozilla-style C++?
Because there's less to remember, and much less to type. Those things
are pretty important, and directly affect time spent writing code.
Almost all of the things you're talking about are build system issues,
and I'm a little surprised that none of them are on the list above, but
perhaps its because they are in a bit of a different category: build
system changes must work 100% when they land -- you can't have your
build system "mostly working."
-Colin
Benjamin Smedberg
> On Wed, 19 Dec 2007 01:14:26 UTC, Mike Schroepfer wrote:
>
>> But, I'd love to enter 2008 with a rough agreement at least on the 1.9.1
>> vs Moz2 issue.
>
> 1.9.1 wasn't really mentioned in your post or I missed it. Do you
> envision the (A) group of tasks to be 2.0 only, and (C) and some of (B)
> to go into 1.9.1 as well? 1.9.1 will still be CVS based, right?
The proposal is that ongoing development will happen in an always-stable
mozilla-central. We will do the next release (Firefox 4) a year after
Firefox 3. The goal is to pick some set of "major" moz2 features to fit in
that timeframe, but if they don't make it we'll still do the release.
So, there is no 1.9.1.
--BDS
steve....@gmail.com
being discussed. But as a nightly tester, bug filer and range-finder,
I have some questions / concerns.
Testing at the moment is easy, since everyone gets the same nightly
and everyone is on the same page. When we have multiple sub-branches,
each dedicated to a large change, testing is going to be seriously
impacted.
To start with, regression range finding will become more complicated
because we will have multiple branches to test that occupy the same
time-line.
What happens when a sub-branch is finished, and the changes get merged
onto the main branch, and then a regression is found using the main
branch? Will the fix first go onto the sub-branch for verification,
and then onto the main branch, or straight onto the main branch?
If it goes straight onto the main-branch then this will make
regression range finding even harder, because we simply won't be able
to check one branch we highly suspect if some of the changes for that
project are on the main branch, and others on the sub-branch. So I
think all sub-branches should remain open, and regression fixes landed
on them before making it onto the main branch.
How are we going to marshal the community of testers? There was talk
of keeping the programmers focused on a max of two branches to
minimize context switching. What about context switching with respect
to testers... The more branches that are actively being developed in
parallel, the less nightly tester time they will receive - either
becuase people will choose to stick with just one branch, or they will
hop between multiple branches more frequently.
What each branch is focused on will also effect the number of testers
that use it. Something like "Major GFX pipeline changes" would
probably interest a lot of testers since it's something palpable we
can test. A branch dedicated to "Centralized security checks" may well
not receive as much testing because it's more abstract and nothing
tangable.
Personally, when I spend time away from testing and then come back, it
always takes me a week or so to get back up to speed as to where the
project is, what's being worked on, what known issues are around, etc.
I am worried that if testers are jumping between different branches
regularly, then people aren't going to be able to keep up with what is
going on with a certain branch. So for that reason I would suggest
keeping the number of branches that need nightly testing to a minimum
as much as possible.
Would it be possible somehow to devise a system where something like
this could happen. Say there are two branches being worked on. Branch
one is tester day, so 24 hours before the nightly is built, the
patches the devs have queued up start to land (one per build) so by
the time the nightly is built all the latest patches are in. Meanwhile
on branch two, the devs are writing patches, but they are not landing,
just getting queued for landing. So this day, Branch one gets the
patches and tester attention.
On day two, Branch Two has tester day. So all the patches that were
queued yesterday start to land (one per build) so when the nightly
build comes around, all the latest patches are landed, and get tested.
Any patches written for Branch One on this day do not land (so there
is no incentive for anyone to test branch one today because it's the
same as yesterday's build). And then on day 3 it's back to Branch One,
etc.
In this way development on both branches would always be ongoing, but
testing would be directed evenly between the two. Patches would land
on an hourly basis so we could find ranges for any regressions found
in the nightly easily. (cf's hourly archive)
Please also give serious consideration to maintaining extension
compatibility as much as possible, and if any fixable regressions are
introduced, acting to resolve them quickly. Us testers have been
spoiled in the past because our extensions have pretty much always
worked on nightly test builds. There are many extensions that we find
it very hard to live without, and if the ability to use extensions is
lost, then I think a lot of testers will choose to stay using a build
where they do work.
Please also take into account testers' bookmarks and history. If we
are testing multiple branches and we have to use different profiles
for each one, then people are going to be less likely to want to test,
since their history and added bookmarks will be scattered between
profiles. At the moment we can't choose to locate our places.sqlite in
a custom location (bug 385077) - If different profiles are going to be
required for different branches, then it would help keep numbers up if
we can keep our bookmarks/history in one place.
It's going to be hard for testers to keep track of multiple branches
that are awlays changing, so we need a good naming system for the
files, but also, I would seriously suggest introducing some default
code that displays the build ID and the branch name in the firefox
title bar by default (at least on the sub-branches, not necessarly the
main branch). Then we will at least be less likely to get confused as
to what build we're on what what we should be testing.
Can breakpad cope with multiple branches each having its own set of
symbols, and will we be able to gather crash stats for each branch
properly?
I've written quite a lot here, and it's not as good as I'd like, but
it's late. There's certainly lots more to consider, both for testers
and other disciplines, so I'll call it a night now. Like I said, this
work is really exciting. understand that multiple branches are the
best way to go when making such big changes to such a large codebase
for moz2, and multiple branches will only ever be used when there's so
many large fundamental changes being made at once.
I think with planning, it's do-able, but the testing aspect of so many
branches still worries me. No matter how you look at it... if you
assume the number of nightly testers is contant, we're going to have
our time split between multiple branches, and that means less testing
in the long run.
/steve
Martijn
> Martijn wrote:
> > On 12/19/07, Benjamin Smedberg <benj...@smedbergs.us> wrote:
> >> * replace mozilla-XBL with XBL2 -- this is probably much easier to implement
> >> correctly and quickly, but it involves rewriting our existing mozilla-XBL
> >> bindings in XBL2. In some cases we can come up with automatic
> >> transformations, but it will still be a pretty huge change that really
> >> should be in bucket A above.
> >
>
> Could you be more specific? Are you concerned about
>
> 1) breaking the web
> 2) destabilizing Firefox itself
> 3) harming XUL application developers who use XBL?
Yeah, I'm particularly concerned about 1) and 3).
Option 2) is just a matter of fixing the stability issues.
I just don't see why Mozilla needs XBL2, I don't think Mozilla needs it.
If XBL2 is causing that much pain, I would say, don't implement it.
Regards,
Martijn
> Of these concerns, I think 2) is most valid. We've said for a long time that
> XBL is not a finished technology, and we've changed it many times already in
> subtle and incompatible ways. Especially if we can provide a simple script
> (XSLT) to convert simple mozXBL -> XBL2 I think that is sufficient.
>
> --BDS
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Martijn Wargers - Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Colin Barrett
> So, there is no 1.9.1.
And this isn't a big deal because we aren't guaranteeing compatibility
with frozen interfaces or any such thing anymore, right?
One thing that isn't on there is actually writing the new embedding
interfaces. Presumably, they will encapsulate Mozilla data structures
and only show embedders platform-native data types a la WebKit.
Is CHBrowserView suitable for something like this? (at least on Mac)
-Colin
Benjamin Smedberg
> On 12/19/07, Benjamin Smedberg <benj...@smedbergs.us> wrote:
>> Could you be more specific? Are you concerned about
>>
>> 1) breaking the web
>> 2) destabilizing Firefox itself
>> 3) harming XUL application developers who use XBL?
>
> Yeah, I'm particularly concerned about 1) and 3).
> Option 2) is just a matter of fixing the stability issues.
Why are you concerned about 1 and 3? Do you have data that we would break
significant parts of the web by making incompatible changes to XBL?
Which extensions or applications use so much XBL that they could not be
fixed for a Firefox 4 release? I know of very few applications that use XBL
so extensively they couldn't be updated with relatively little effort.
> I just don't see why Mozilla needs XBL2, I don't think Mozilla needs it.
> If XBL2 is causing that much pain, I would say, don't implement it.
Mozilla XBL is causing the pain currently. We spend inordinate amounts of
startup and txul time compiling XBL attributes and event handlers, and the
behavior of XBL is under-specified at best.
XBL2 was a fairly carefully-defined specification that is much more careful
about how bindings are applied, unapplied, and separated from the document
logic. It should provide speed and stability benefits compared to the
current XBL implementation. It will also make writing bindings less
'magical', and it is likely that webkit will implement XBL2 at some point as
well, proving for a standardized binding language.
--BDS
Benjamin Smedberg
> And this isn't a big deal because we aren't guaranteeing compatibility
> with frozen interfaces or any such thing anymore, right?
This was discussed on the call today: we know we need an embedding
interface... we don't know how much we can or want to support "binary XPCOM
components" once XPCOMGC lands.
> One thing that isn't on there is actually writing the new embedding
> interfaces. Presumably, they will encapsulate Mozilla data structures
> and only show embedders platform-native data types a la WebKit.
>
> Is CHBrowserView suitable for something like this? (at least on Mac)
I was going to ask you that... we would like an embedding interface that is
completely usable without having the embedding know about XPCOM. This means
that the embedding API provides hooks for prompt providers and other
features. It may also require reflecting the DOM into an embedding
interface; I'm not so sure about the actual requirements. I would love if we
could expose the DOM to embedders via the scriptable NPAPI interface, which
has the advantage that it's already implemented.
--BDS
Simon Paquet
> Which extensions or applications use so much XBL that they could not be
>fixed for a Firefox 4 release? I know of very few applications that use XBL
>so extensively they couldn't be updated with relatively little effort.
Both calendar apps (Sunbird & Lightning) make pretty heavy use of XBL at
the moment.
I don't know how much work it would be to update that code to XBL2,
though.
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Schrep
<steve.engl...@gmail.com> wrote:
Steve - first off thanks for your feedback here! Let me try and
comment in-line:
> What happens when a sub-branch is finished, and the changes get merged
> onto the main branch, and then a regression is found using the main
> branch? Will the fix first go onto the sub-branch for verification,
> and then onto the main branch, or straight onto the main branch?
Once you get merged unless we back out you are merged. The meta-goal
here is to try and be better about catching issues before we merge.
Our much improved automated perf and regression testing will help a
ton for sure. But there is no magic here - the hardest part will be
having the discipline to only merge when it is really ready to do so.
> How are we going to marshal the community of testers? There was talk
> of keeping the programmers focused on a max of two branches to
> minimize context switching. What about context switching with respect
> to testers... The more branches that are actively being developed in
> parallel, the less nightly tester time they will receive - either
> becuase people will choose to stick with just one branch, or they will
> hop between multiple branches more frequently.
>
> What each branch is focused on will also effect the number of testers
> that use it. Something like "Major GFX pipeline changes" would
> probably interest a lot of testers since it's something palpable we
> can test. A branch dedicated to "Centralized security checks" may well
> not receive as much testing because it's more abstract and nothing
> tangable.
Yep - as I said in an earlier post we also need to be careful about
sub-diving the testing community too far.
> Please also give serious consideration to maintaining extension
> compatibility as much as possible, and if any fixable regressions are
> introduced, acting to resolve them quickly. Us testers have been
> spoiled in the past because our extensions have pretty much always
> worked on nightly test builds. There are many extensions that we find
> it very hard to live without, and if the ability to use extensions is
> lost, then I think a lot of testers will choose to stay using a build
> where they do work.
>
Yea - good point. What extensions in particular? Nightly tester
tools? This is going to be a tough one with the sorts of changes
going into Moz2 so I'd say if we can get a small set of extensions
that are critical we can do the work as we go to update them as
needed.
> Please also take into account testers' bookmarks and history. If we
> are testing multiple branches and we have to use different profiles
> for each one, then people are going to be less likely to want to test,
> since their history and added bookmarks will be scattered between
> profiles. At the moment we can't choose to locate our places.sqlite in
> a custom location (bug 385077) - If different profiles are going to be
> required for different branches, then it would help keep numbers up if
> we can keep our bookmarks/history in one place.
>
Hrm. Hopefully this won't be necessary - but it is something to look
out for.
> It's going to be hard for testers to keep track of multiple branches
> that are awlays changing, so we need a good naming system for the
> files, but also, I would seriously suggest introducing some default
> code that displays the build ID and the branch name in the firefox
> title bar by default (at least on the sub-branches, not necessarly the
> main branch). Then we will at least be less likely to get confused as
> to what build we're on what what we should be testing.
Yea - we could be lots better about default nightlies having more info
for sure.
> Can breakpad cope with multiple branches each having its own set of
> symbols, and will we be able to gather crash stats for each branch
> properly?
Dunno but now the server and the client are all opensource. So if we
do something intelligent with the buildids it should all be fine.
>
> I've written quite a lot here, and it's not as good as I'd like, but
> it's late. There's certainly lots more to consider, both for testers
> and other disciplines, so I'll call it a night now. Like I said, this
> work is really exciting. understand that multiple branches are the
> best way to go when making such big changes to such a large codebase
> for moz2, and multiple branches will only ever be used when there's so
> many large fundamental changes being made at once.
>
> I think with planning, it's do-able, but the testing aspect of so many
> branches still worries me. No matter how you look at it... if you
> assume the number of nightly testers is contant, we're going to have
> our time split between multiple branches, and that means less testing
> in the long run.
Yep, lots of hard work and planning to do here. But we know how to do
that :-). Thanks for your thoughts!
Boris Zbarsky
> I just don't see why Mozilla needs XBL2
Some reasons:
1) It provides features that XBL1 doesn't (e.g. bindings attached
independently of CSS).
2) It has a clearly defined processing model for the shadow tree
(the XBL1 one is underdefined and only half-implemented, though
at this point as a result of security fixes it may be
3/4-implemented).
3) It provides security benefits by design (no scope mixing,
for example).
4) It provides performance and likely footprint benefits, as Benjamin
said.
5) It's easier for an XBL author to use (e.g. fires more useful
events).
-Boris, in his little-used XBL module owner hat
Mike Shaver
> I think that from the average developers point of view the road blocks
> to faster development are things like how fast can I go from code change
> to code-test, and from there to commit, and from there to release. And
> in reverse, how fast can I go from bug report to code change.
I think we might be talking about developer productivity differently.
Here are the three paths I think of to improved developer
productivity, with some examples from the post-1.9 plan outlined in
this thread:
Fewer "steps" to get to the same result: worker threads instead of
setTimeout decomposition or playing chicken with nsIThreadManager is
one example. You can do parallel and async computation now, but you
gotta really want it. So instead of either living with UI chunkiness
on large inputs, or sticking an immersion blender into your emacs
buffer, you have a handful of easy-to-use tools for computing in
parallel, and possibly even mutating the UI in a way that feels
parallel to the programmer.
Better results for the same steps: many of the visual improvements and
even XUL fixes, and definitely not needing to drop into C++ to get
adequate performance for a lot of cases that used to require it.
(Related to the above: less time optimizing means more time writing
nice new features.)
Same result, same steps, but make the steps faster: I think this is
what you're talking about, making incremental refinements to existing
workflow. XBL2 and XUL box model improvements so you spend fewer
cycles debugging stuff that should just work...but doesn't because
your node isn't in a document yet, or your content is in a popup, or
you're using a XUL element in an HTML document instead of a XUL
document, etc. JS2 alone will let you express a lot more of the
constraints your code wants enforced around it, giving you better
diagnostics as well as eliminating entire classes of runtime error.
Ask for it by name!
Putting myself back into the mindset I had when last I was heads-down
on app-level code (my days as a Lightning/Sunbird hacker), I am hot
for many of these planned features. Had they been available in those
days, I would have been able to have a better app earlier; the very
definition of improved developer productivity! (I would probably have
chewed off my own arm for even _two_ of them, especially if I got to
choose them, and there were paramedics to hand.)
I'm pretty sure that tools like Komodo -- and maybe even this Firebug
thing that I hear so much about! :) -- will benefit from the better
capabilities in a way that translates quite directly to improvements
in their user experience, which means improvements in developer
productivity.
Out of scope for Gecko and the apps, Bugzilla is growing an API as
well, of course, which will in time make it easier for tools to
integrate with it. (The API is some quaint XML-RPC concoction, rather
than being all REST and easy to work with, but we take our baby steps
where we can get them.)
Mike
Robert O'Callahan
> One of the strengths of the Web platform over
> proprietary plugins is that the Web is better for mixing up different
> kinds of content. (Web content can contain any other kind of content;
> Flash content can only contain Flash.)
Heh, and check this out:
http://www.onflex.org/ted/2007/12/yahoo-maps-from-flex-15-to-ajax.php
Yahoo Maps dropped Flash in favour of AJAX, and one of the reasons is
precisely what I just said --- in particular, they had trouble serving
ads in their Flash app. The Adobe evangelist points out that they'll
be able to serve Flash ads in Flash apps more easily in some future
version of Flash, but so what --- if they want to use HTML ads or
Silverlight ads or whatever the next big thing is (SVG?), they're
stuck.
Rob
Colin Barrett
> Colin Barrett wrote:
>
>> And this isn't a big deal because we aren't guaranteeing compatibility
>> with frozen interfaces or any such thing anymore, right?
>
> This was discussed on the call today: we know we need an embedding
> interface... we don't know how much we can or want to support "binary XPCOM
> components" once XPCOMGC lands.
I suspect extensions probably want *some* way to run C/C++/ObjC code,
XPCOM or otherwise. Perhaps jsctypes?
>> One thing that isn't on there is actually writing the new embedding
>> interfaces. Presumably, they will encapsulate Mozilla data structures
>> and only show embedders platform-native data types a la WebKit.
>>
>> Is CHBrowserView suitable for something like this? (at least on Mac)
>
> I was going to ask you that... we would like an embedding interface that is
> completely usable without having the embedding know about XPCOM.
100% agree.
> This means
> that the embedding API provides hooks for prompt providers and other
> features. It may also require reflecting the DOM into an embedding
> interface; I'm not so sure about the actual requirements. I would love if we
> could expose the DOM to embedders via the scriptable NPAPI interface, which
> has the advantage that it's already implemented.
That certainly sounds reasonable.
hold...@gmail.com
> > >> * replace mozilla-XBL with XBL2 -- this is probably much easier to implement
> > >> correctly and quickly, but it involves rewriting our existing mozilla-XBL
> > >> bindings in XBL2. In some cases we can come up with automatic
> > >> transformations, but it will still be a pretty huge change that really
> > >> should be in bucket A above.
>
> > > Removal of current mozilla-XBL sounds like a very bad idea to me.
>
> > Could you be more specific? Are you concerned about
>
> > 1) breaking the web
> > 2) destabilizing Firefox itself
> > 3) harming XUL application developers who use XBL?
>
> Yeah, I'm particularly concerned about 1) and 3).
> Option 2) is just a matter of fixing the stability issues.
>
> I just don't see why Mozilla needs XBL2, I don't think Mozilla needs it.
> If XBL2 is causing that much pain, I would say, don't implement it.
>
> Regards,
> Martijn
>
> > Of these concerns, I think 2) is most valid. We've said for a long time that
> > XBL is not a finished technology, and we've changed it many times already in
> > subtle and incompatible ways. Especially if we can provide a simple script
> > (XSLT) to convert simple mozXBL -> XBL2 I think that is sufficient.
>
> > --BDS
I apologize if this is already well known, but is there still any talk
about moving the interface to HTML widgets written in XBL(1 or 2)?
Peter Weilbacher
> Benjamin Smedberg wrote:
>
>> So, there is no 1.9.1.
Ah! That is completely different than what was said before.
> And this isn't a big deal because we aren't guaranteeing compatibility
> with frozen interfaces or any such thing anymore, right?
>
> One thing that isn't on there is actually writing the new embedding
> interfaces. Presumably, they will encapsulate Mozilla data structures
> and only show embedders platform-native data types a la WebKit.
So it would be best for embedders to _not_ move from Gecko 1.8.x to 1.9
now, because after only a year they would have to rewrite almost
everything anyway to use 2.0?
Peter.
Sergey Yanovich
> Benjamin Smedberg wrote:
>> interface... we don't know how much we can or want to support "binary
>> XPCOM
>> components" once XPCOMGC lands.
>
> I suspect extensions probably want *some* way to run C/C++/ObjC code,
> XPCOM or otherwise. Perhaps jsctypes?
Excellent point.
I am developing a enterprise resource planning system, and here is why
it is a XUL application:
1. Portable performance. I can build platform-independent native code to
perform heavy calculations on the client side to reduce server and
network load. Mozilla tree is a collection objects to perform all kind
of tasks with carefully designed interfaces.
2. Multiple inheritance. XPCOM + XPIDL is a near heaven for GoF design
pattern implementations. Only getter_AddRefs and NS_ENSURE_* spoil the
nice picture.
3. Scripting. Scriptable controller + nsIObserverService + XBL +
overlays mix is a ready MVC solution, easy to write and debug with
jsconsole, and easy to extend in future.
4. Popular UI framework. People like their applications to look familiar
to them.
I was crying 'w00t' to myself, when I first heard about XPCOMGC and C++
exceptions rewrites, as they will remove getter_AddRefs and NS_ENSURE_*.
But phrases like
> we don't know how much we can or want to support "binary XPCOM components"
make me really nervous. I really need to run mozilla C/C++/ObjectiveC
code, and I really need to build my own native code, that can be invoked
from js.
Most probably, I am not alone. This issue probably concerns anyone, who
has native XPCOM code: Thunderbird, Sunbird/Lightning, Songbird, Komodo,
other XUL applications and numerous extensions.
--
Sergey Yanovich
Sergey Yanovich
> So it would be best for embedders to _not_ move from Gecko 1.8.x to 1.9
> now, because after only a year they would have to rewrite almost
> everything anyway to use 2.0?
I am not sure about embedders, but I see nothing that prevents automatic
rewrite tools to be applied to XR application code in the same way, it
will be applied to the mozilla tree.
--
Sergey Yanovich
John J. Barton
> John J Barton wrote:
>> I think that from the average developers point of view the road blocks
>> to faster development are things like how fast can I go from code
>> change to code-test, and from there to commit, and from there to
>> release. And in reverse, how fast can I go from bug report to code
>> change. For new code, the biggest barrier is platform complexity; for
>> new developers the dev environment setup is a huge barrier. This
>> would argue for better support of dependency analysis, incremental
>> composition of modules, even deeper integration with online systems
>> like breakpad, bugzilla, and mdc, as well as better dev tools tailored
>> for mozilla rather than windows or linux.
>
> I think you vastly underestimate how much things like garbage collection
> will help. No more time spent thinking about memory management.
MMgc is an alternative memory manager rather than true GC. I think it
will help rather than revolutionize.
> Exceptions mean you don't need to worry about formating your code so
> doing all the required nsresult error checking doesn't result in huge
> numbers of indents.
Yes, I think this one will be a big win.
> A lot of these things will make writing Mozilla code so much smoother
> and cleaner and /more understandable/. If you can hold more of the
> codebase in your head at once, you don't have to hit mxr and re-page all
> of that knowledge back in.
I can see that these changes will dramatically improve developer
productivity for C++ Mozilla code. I was thrown off by not realizing
that in this context "Developer productivity" really means "C++
developer productivity".
> Why am I able to write python or JS much quicker than mozilla-style C++?
> Because there's less to remember, and much less to type. Those things
> are pretty important, and directly affect time spent writing code.
Well I disagree about the cause and effect, but I agree that making
mozilla C++ less ridiculous will make mozilla better.
Benjamin Smedberg
> MMgc is an alternative memory manager rather than true GC. I think it
> will help rather than revolutionize.
What do you mean by a "true GC"? MMgc is a conservative mark and sweep
garbage collector, and switching to GC from reference counting is a pretty
major paradigm shift by itself. Unifying the JS and XPCOM heap and avoiding
lots of code to manage reference cycles is where we'll get major
productivity enhancements.
> I can see that these changes will dramatically improve developer
> productivity for C++ Mozilla code. I was thrown off by not realizing
> that in this context "Developer productivity" really means "C++
> developer productivity".
We have already spent significant effort on JS developer productivity with
JS modules, FUEL, and other wrapper libraries. JS2 by itself will be a
*huge* win for JS developer productivity because of the typed-code guarantees.
--BDS
John J. Barton
> On Dec 19, 2007 5:48 PM, John J Barton <johnj...@johnjbarton.com> wrote:
>> I think that from the average developers point of view the road blocks
>> to faster development are things like how fast can I go from code change
>> to code-test, and from there to commit, and from there to release. And
>> in reverse, how fast can I go from bug report to code change.
>
> I think we might be talking about developer productivity differently.
> Here are the three paths I think of to improved developer
> productivity, with some examples from the post-1.9 plan outlined in
> this thread:
>
> Fewer "steps" to get to the same result: worker threads instead of
> setTimeout decomposition or playing chicken with nsIThreadManager is
> one example. You can do parallel and async computation now, but you
> gotta really want it. So instead of either living with UI chunkiness
> on large inputs, or sticking an immersion blender into your emacs
> buffer, you have a handful of easy-to-use tools for computing in
> parallel, and possibly even mutating the UI in a way that feels
> parallel to the programmer.
Sorry I disagree. In my experience setTimeout decomposition is very
productive compared with say Java threading. 'Easy-to-use' and
'parallel' just can't go together. What's true for people is true for
code: you can't share something without agreeing on who gets it when.
>
> Better results for the same steps: many of the visual improvements and
> even XUL fixes, and definitely not needing to drop into C++ to get
> adequate performance for a lot of cases that used to require it.
> (Related to the above: less time optimizing means more time writing
> nice new features.)
>
> Same result, same steps, but make the steps faster: I think this is
> what you're talking about, making incremental refinements to existing
> workflow.
No, I'm talking about improving the JS tools, better support for
inter-module rather than intra-module development, and improvements in
team interaction. Not that the other stuff isn't good, just not what I
was looking for.
> XBL2 and XUL box model improvements so you spend fewer
> cycles debugging stuff that should just work...but doesn't because
> your node isn't in a document yet, or your content is in a popup, or
> you're using a XUL element in an HTML document instead of a XUL
> document, etc. JS2 alone will let you express a lot more of the
> constraints your code wants enforced around it, giving you better
> diagnostics as well as eliminating entire classes of runtime error.
> Ask for it by name!
Great, a giant leap backwards to the 1980s.
...
> Out of scope for Gecko and the apps, Bugzilla is growing an API as
> well, of course, which will in time make it easier for tools to
> integrate with it.
Yes, I now understand that my point of view out of scope for Mike's
list. All this stuff is good and important, for the intended audience.
John J. Barton
> John J. Barton wrote:
>
>> MMgc is an alternative memory manager rather than true GC. I think it
>> will help rather than revolutionize.
>
> What do you mean by a "true GC"? MMgc is a conservative mark and sweep
> garbage collector, and switching to GC from reference counting is a pretty
> major paradigm shift by itself. Unifying the JS and XPCOM heap and avoiding
> lots of code to manage reference cycles is where we'll get major
> productivity enhancements.
As I understand it, only allocations from MMgc are collected and it's
not thread safe. So it requires special coding and thought. Still great
and good, but its not GC for C++.
>
>> I can see that these changes will dramatically improve developer
>> productivity for C++ Mozilla code. I was thrown off by not realizing
>> that in this context "Developer productivity" really means "C++
>> developer productivity".
>
> We have already spent significant effort on JS developer productivity with
> JS modules, FUEL, and other wrapper libraries. JS2 by itself will be a
> *huge* win for JS developer productivity because of the typed-code guarantees.
Both Java and Javascript added more typing after they were widely
considered to be productive systems while languages with strong typing
from Day One are never heard of again. Accident? Perhaps.
Mark Banner
> Tasks:
Here's a couple of my own thoughts that I'd have liked to have seen on
the list. These may be on the "plan", but I'd like to mention them anyway.
1) Removal of the Obsolete APIs - http://wiki.mozilla.org/Gecko:Obsolete_API
If we're doing an API rework to tidy things up, surely now is the time
to get rid of these.
Not sure where these would fall, but I'd probably to put them as medium
sized, because some of them go quite deep into the code.
2) xulrunner
What's happening to this? Given the way the source code control/build
structure seems to going, being able to build apps with xulrunner
properly would seem to be useful/appropriate.
I don't know how much work there is to get this going, but I expect it
would be useful to folks to find out.
Standard8
Benjamin Smedberg
> As I understand it, only allocations from MMgc are collected and it's
> not thread safe. So it requires special coding and thought. Still great
> and good, but its not GC for C++.
We're not really looking for "GC for C++", we want "GC for Mozilla". We have
already implemented thread safety using the spidermonkey request model, and
have a prototype tree where all XPCOM objects are allocated and managed by
the garbage collector.
We have no intention of making every C++ allocation garbage-collected...
that would perform poorly for large allocations and is entirely unnecessary.
Just the COM object graph must participate in GC.
--BDS
Michiel van Leeuwen
> Colin Barrett wrote:
>
>> And this isn't a big deal because we aren't guaranteeing compatibility
>> with frozen interfaces or any such thing anymore, right?
>
> This was discussed on the call today: we know we need an embedding
> interface... we don't know how much we can or want to support "binary XPCOM
> components" once XPCOMGC lands.
I'm quite sure there are extensions that need some way to talk to some
binary library (calendar comes to mind, which needs libical). The
current solution is a binary xpcom component. So (unless there is some
alternative ofcourse) binary components can't just go away.
(Or am I misunderstanding what you are talking about?)
Michiel
Justin Wood (Callek)
> And on the seventh day Benjamin Smedberg spoke:
>
>> Which extensions or applications use so much XBL that they could not be
>> fixed for a Firefox 4 release? I know of very few applications that use XBL
>> so extensively they couldn't be updated with relatively little effort.
>
> Both calendar apps (Sunbird & Lightning) make pretty heavy use of XBL at
> the moment.
>
> I don't know how much work it would be to update that code to XBL2,
> though.
For what it is worth, so does SeaMonkey, but in terms of what XBL2 does
for us, that current XBL does, the "effort to update" is of considerable
gain vs "what time we loose" imho.
And I should assume that Sunbird/SeaMonkey would be of the higher tier
apps to have assistance should XBL2 come to play as Ben is suggesting.
And that he was most likely (though I can't speak for him, I am speaking
of an assumption)... most likely talking about external applications,
such as "Songbird" or [open]Komodo, etc.
--
~Justin Wood (Callek)
Justin Wood (Callek)
> [alot] :-)
Hmm, for the ignorant on specifics, (like myself) any links to the
details of some of the following work:
> 5) Better threading support in the core layout engine
> 6) Centralized security checks
> 8) Major GFX pipeline changes
> 9) Protected mode
And that for
> 7) Removal of XPConnect
Specifically, as I want to be sure that a JS<->C++ bridge is still
there, even if not called "XPConnect" in some way. :-)
> 5) Treaded parsing
> 6) Threaded image decoding
those mean what?
> 1) Worker threads
> 4) Jail tag
> 7) Tabs between windows
I'm also confused as to what these mean (less confused on #1 but still a
bit.
Thanks for enlightening the ignorant (in this case, me)
--
~Justin Wood (Callek)
Mook
Yes, Songbird uses a crapload of XBL - pretty much everything is. We
basically have skins that are really extensions (so the XUL can be
rearranged in content packages), hence the XBL-ness. Lack of XBL(1)
would indeed involve a costly porting effort for us.
Of course, lack binary XPCOM components would probably hurt a lot more.
I don't think Mozilla is quite ready yet to be a full media platform
(complete with tons of codecs, etc.); we definitely need those things.
I suppose that would mean we would need to ship our things as internal
linkage? (We already build XULRunner anyway, due to a small number of
patches)
<insert disclaimer about not having much of a clue about Songbird vis.
Mozilla 2>
--
Mook
sleepy and relatively low on the local food chain
Myk Melez
> > 7) Removal of XPConnect
> Specifically, as I want to be sure that a JS<->C++ bridge is still
> there, even if not called "XPConnect" in some way. :-)
Presumably that bridge (and the replacement for binary XPCOM components)
is JS-CTYPES
<http://starkravingfinkle.org/blog/2007/09/hello-js-ctypes-goodbye-binary-components/>
-myk
Sergey Yanovich
IIUC, js-ctype is JS->C, while xpconnect is JS<->C++.
Among other things xpconnect enables calls to JS XPCOM modules from
native code, like in nsDefaultCLH.js. js-ctypes don't look to allow for
this type of interoperability, which is replied upon not only in most
XUL apps, but also in firefox itself.
js-ctypes need to be extended with JS<-C bridge of some type to actually
replace xpconnect.
--
Sergey Yanovich
John J. Barton
> Mike Schroepfer wrote:
>> [alot] :-)
>
> Hmm, for the ignorant on specifics, (like myself) any links to the
> details of some of the following work:
Yes, I (obviously ;-) didn't understand a lot of the list. A few lines
on how each change will address the goals would help a lot.
John.
christophe...@gmail.com
I'm pretty worried about this. Partially because I care a lot about
our embedders and the pain that they currently feel, but also because
I worry that we're making things harder for them instead of easier in
the new world.
I have a strong emotional reaction to the NPAPI interface. Mostly
because I spent a lot of time with it when I worked on plugins in Gtk
so I kind of hate it. Or are you referring to the NPAPI interface
that plugins can use to get access to the DOM? I haven't played with
that - I don't know what it looks like.
I know that one of your big worries is being asked to keep things
stable and people embedding the engine into other apps forcing that on
you. I'm not sure if hiding the new XPCOM (whatever it ends up
looking like) is going to keep that problem from happening. Might it
instead be possible to give people a set of interfaces that would make
the new mmgc work easier to consume and understand? It seems to me
that there's a huge number of things to be gained from allowing people
to take advantage of the memory and lifetime characteristics that a GC
system provides. Especially since they are going to have to deal with
it, hidden or not, when they touch bits of content or want to embed
the browser.
In the end I think that making complex systems easier to approach and
use is probably a winning strategy vs. hiding it entirely. It feels
like another layer of abstraction that doesn't add a huge amount of
value when making our interfaces approachable is something we need to
do in any case and is more in line with our goals for Moz2 (reduced
complexity/increased developer productivity.)
Also, I keep hearing about these changes and I worry about them. Are
you to the point where you can start posting code samples of how
things might look like in the new mmgc world for embeddors or other
consumers to look at? I think that would make things a lot more
concrete.
kherrick
> > 7) Removal of XPConnect
> Specifically, as I want to be sure that a JS<->C++ bridge is still
> there, even if not called "XPConnect" in some way. :-)
Ted Mielczarek
<steve.engl...@gmail.com> wrote:
> Can breakpad cope with multiple branches each having its own set of
> symbols, and will we be able to gather crash stats for each branch
> properly?
Sort of an offhand comment on an old post on a thread I wasn't
following closely, but yes, this works fine. We already used this in
the past to have crash reporting on roc's new textrun builds alongside
normal trunk builds.
-Ted
Colin Barrett
> I'm not sure if hiding the new XPCOM (whatever it ends up
> looking like) is going to keep that problem from happening. Might it
> instead be possible to give people a set of interfaces that would make
> the new mmgc work easier to consume and understand? It seems to me
> that there's a huge number of things to be gained from allowing people
> to take advantage of the memory and lifetime characteristics that a GC
> system provides. Especially since they are going to have to deal with
> it, hidden or not, when they touch bits of content or want to embed
> the browser.
Here's an example that might illustrate where bsmedberg and I are coming
from:
Say I'm writing a Cocoa application, and I want to use Gecko to render
some HTML in my interface. I don't want to have to deal with some crazy
Mozilla interface in C++. I want to use Objective C, create an NSView,
drop it in, set my own object as a delegate to control things, load
NSURLs and such.
If I need to transform the content a bit more, there should be ways to
apply XSL tranforms, run Xpath queries, run bits of JS, have those call
my own ObjC methods, vend objects, etc, all from ObjC.
And if I absolutely need it, then there's an unsupported
this-may-break-at-any-time way to access internal Mozilla data structures.
This is how the WebKit embedding API on the Mac is set up, and it makes
a lot of sense. Note that WebCore and JSCore are written in C++, and
only the API wrapper layer is ObjC.
bsmedberg talked about wanting to do similar things on both Linux and
Windows, and I think it makes a lot of sense. Being able to drop in an
HTML rendering engine with minimal work and being able to control it in
a way that's expected and makes sense to a developer who is not familiar
with Mozilla would be pretty sweet.
(sorry about bumping this thread)
-Colin
Aaron Leventhal
changes are still very important (and probably easiest to underestimate
in terms of resource requirements).
I'm concerned that we as developers love to do the next big thing, and
many annoying, difficult to fix issues just get ignored. As a community
we attract new developers to work on cool new things, but we also need
maintainers willing to do the tedious work in brittle unowned modules,
fixing one boring bug at a time.
We won't always rewrite everything -- focus is a great example.All you
have to do is look in bugzilla for things like focus issues and you can
easily find pretty important bugs. Of course I have my hidden agenda
here -- I really think we should deal with the specific issue of
keyboard navigation in plugins. But, I believe there is a general issue
here. It takes a lot more resources than anyone wants to admit to just
"fix bugs" in the core. There are areas that no one really wants
responsibility for -- the next big rewrite or big standard is more
interesting.
- Aaron
- Aaron
Mike Schroepfer wrote:
> Hey There,
>
> We've had a number of good discussions in the recent Mozilla 2 meetings
> about what we want to accomplish, and the work on ActionMonkey is
> progressing well: http://wiki.mozilla.org/JavaScript:ActionMonkey.
>
> I wanted to get some thoughts out on how to plan the next major Gecko
> release. Some of this is re-hash from the Moz2 meetings - so bear with
> me. Short version: I think we should work towards a Moz2 release as the
> next release. We will also continue on a variety of lower-risk tasks in
> parallel and aim one way or another to release another major version ~1
> year after Firefox3.
>
> Longer Explanation:
>
> Definition: Moz2 means we can break API compatibility (hence
> incrementing the major version number). That's it. It is implied that
> some of the bigger changes below may either require us to break API
> compat or may be substantially easier to do if we break compat.
>
> Overall Goals (not in a particular order and stolen from Moz2 meeting):
> * Improve developer productivity
> * Performance
> * Footprint
> * Security
> * Innovative web features
> * Improved embedding and mobile support
> * Building features in XUL needed by apps
> * Better Support multicore systems
> * Continuing to improve our UE
>
> Goals of our Process:
>
> We are building Mozilla for the long-run. Our primary goal is to push
> the web forward. Firefox is the current instrument of that mission and
> we should seek to maximize long-term development/product productivity.
> We don't have any quarter-end, trade-show, or other artificial deadlines
> which force us to make short term decisions that are detrimental to the
> long-term. On the other hand, most of us are at Mozilla to ship software
> that real people use. So I'd like us to ship as frequently as possible
> but make decisions that ensure a long-term continuous stream of high
> quality products from Mozilla. Shooting for the best product delievery
> and engineering efficiency over a span of years is the goal here.
>
> Release Date:
>
> Firefox 1.5 shipped just over 1 year from Firefox 1.0
> Firefox 2.0 shipped about 11 months after Firefox 1.5
> Firefox 3.0 (if ships in 1H08) will ship 17-30 months after Firefox 2.0
> (but was under development for closer to 2-3 years)
>
> Given our goals, past experience, it feels right to set a target for the
> follow-on to Firefox 3 to ship about 1 year from Firefox 3. That should
> give us enough time to make progress on the big long-term stuff but
> isn't too long to compound risk. This is an interpolation between the
> times of Firefox 3 and Firefox 2.
>
> Tasks:
>
> I'd like us to think of our tasks in three rough buckets. These buckets
> are meant to categorize things mostly by level of risk to the overall
> release. I've likely got the specific tasks in bucket B/C wrong (since
> we haven't done this yet and this is a swag) but we can address later
> here. Thinking of things in these buckets is more important this second
> that the specific tasks.
>
> A) Big, invasive, destabilizing changes. These are the sort of tasks
> that don't respond well to compression (e.g. throwing more people at it)
> and touch large pieces of the code and/or can destabilize other parts of
> the development. These are the sort of changes that once landed into the
> mainline development tree can become the long-pole for release and are
> difficult to unwind. From the Moz2 meetings it appears the following are
> in this category:
> 1) mmGC (including XPCOMGC) *already underway*
> 2) Exception support *already underway for tooling at least*
> 3) deCOM
> 4) Taramin JIT replacing SM *already underway*
> 5) Better threading support in the core layout engine
> 6) Centralized security checks
> 7) Removal of XPConnect
> 8) Major GFX pipeline changes
> 9) Protected mode
>
> B) Medium sized, significant in impact changes. These are non-trival,
> but better isolated. Easier to turn off or backout. Things such as:
> 1) XBL2
> 2) Frame construction cleanup
> 3) Inline re-flow
> 4) XUL box Model
> 5) Treaded parsing
> 6) Threaded image decoding
> 7) Fewer restarts (e.g. protected extension installs, etc)
> 8) Features needed for UE
> 9) UE improvements
>
> C) Smaller, isolated changes. These are smaller, easy to turn off, or
> don't impact other critical paths:
> 1) Worker threads
> 2) Video
> 3) Minor CSS improvements
> 4) Jail tag
> 5) SVG animation
> 6) SVG fonts
> 7) Tabs between windows
> 8) UE improvements
>
> Plan:
>
> We should pick 2-3 of the most important large tasks and prioritize them
> as a #1 priority and resource them for success. This means as folks peel
> off of Gecko 1.9 they should first try to help with these 2-3 large
> tasks. Because we have a huge and awesome community, and because many of
> these tasks don't parallelize well we'll have plenty of resources left
> over to crank on items from buckets B and C.
>
> We organize into teams so that each area has at least 2 folks working on
> it (to prevent blocking on reviews, etc) and no more than 5-6 folks on
> it (just too much communication overhead). Each feature team takes an
> area from start to finish - e.g. don't start new tasks until this one is
> done (to prevent end-game context switching and release risk). Ideally
> no one person should be working on more than 1 (or maybe 2) features at
> once (again to prevent context switching).
>
> Each team (depending on size of task) will be working on a separate Hg
> branch. We'll keep hg-central overall very high quality and
> ready-to-ship. Merges to hg-central will not be allowed without
> regression, performance, functionality parity. No more landing then
> optimizing. We'll organize the tasks to prevent merge conflicts wherever
> possible. This is why we can't undertake too many large items at once.
> Easier Hg merging, the try server, and other tools will make it much
> easier for folks to test out changes without first having to merge them
> to mainline.
>
> We ship alpha's from hg-central early on in the process on a 6-8 week
> cadence. We'd strongly hope that 1-3 of the big (A) tasks is ready for
> ship during the schedule. However, since we are working on lots of
> smaller stuff in parallel if the big stuff takes longer than expected we
> still have a stable base and a set of improvements to go into a release.
>
> This gives us a couple of things:
> a) It ensures that the big long-pole items of high impact are never
> starved and are delivered as soon as possible
> b) We don't take on *too* many of them at once and have to deal with
> with challenges of compound regressions, performance issues, etc.
> c) Gives us the ability to ship more easily if some of the big tasks
> take too long
> d) Tries to reduce the context-switch overhead that was hard on many
> folks during the Firefox 3 release
> e) The constant quality of the mainline makes it easier to isolate
> changes, regressions,and be ready to ship.
>
> So in short I think we need to courage to take on a few big tasks and
> resource them for success, and the wisdom to not block all development
> behind these tasks.
>
> Thoughts? There are obviously many many details to nail down in terms of
> prioritizing and ordering tasks, etc. and that will take some time. But,
> I'd love to enter 2008 with a rough agreement at least on the 1.9.1 vs
> Moz2 issue.
>
> Best,
>
> Schrep
>
>
>
>
>
>
gerri
<bugzi...@invalid.standard8.plus.com> wrote:
> Mike Schroepfer wrote:
> > Tasks:
>
> Here's a couple of my own thoughts that I'd have liked to have seen on
> the list. These may be on the "plan", but I'd like to mention them anyway.
>
>
> If we're doing an API rework to tidy things up, surely now is the time
> to get rid of these.
>
> Not sure where these would fall, but I'd probably to put them as medium
> sized, because some of them go quite deep into the code.
>
> 2)xulrunner
>
> What's happening to this? Given the way the source code control/build
> structure seems to going, being able to build apps withxulrunner
> properly would seem to be useful/appropriate.
>
> I don't know how much work there is to get this going, but I expect it
> would be useful to folks to find out.
Right, I really would like to know when the stable 1.9 version of
xulrunner will be released. It seems that the official roadmap hasn't
been updated recently and I am waiting for the new version badly. I'm
thankful for any info on that topic.
Mike Schroepfer
> Both Java and Javascript added more typing after they were widely
> considered to be productive systems while languages with strong typing
> from Day One are never heard of again. Accident? Perhaps.
Er?
Java first edition published 1996: "Java is a strongly typed language,"
http://java.sun.com/docs/books/jls/first_edition/html/4.doc.html#95845
Did you mean something else?
Gijs Kruitbosch
Well, one thing that Java did add later (only comparatively recently, in
fact) is generics, as compiletime substitute for the runtime casting
that everyone had been using before. This, to some extent, allows you to
make your code more 'strict' about typing, while keeping it versatile.
(for anyone who hasn't heard of generics, I suppose it will do to think
of them as being a little like C++ templates, even though they're really
not - more info at
http://java.sun.com/developer/technicalArticles/J2SE/generics/ )
I'm not sure if that's what the OP meant though, or how strong an
example it is. :-)
~ Gijs
John J. Barton
> Mike Schroepfer wrote:
>>
>>> Both Java and Javascript added more typing after they were widely
>>> considered to be productive systems while languages with strong
>>> typing from Day One are never heard of again. Accident? Perhaps.
>>
>> Er?
>>
>> Java first edition published 1996: "Java is a strongly typed language,"
>>
>> http://java.sun.com/docs/books/jls/first_edition/html/4.doc.html#95845
>>
>> Did you mean something else?
Yes, I should know better than use "strong typing".
>
> Well, one thing that Java did add later (only comparatively recently, in
> fact) is generics, as compiletime substitute for the runtime casting
> that everyone had been using before. This, to some extent, allows you to
> make your code more 'strict' about typing, while keeping it versatile.
> (for anyone who hasn't heard of generics, I suppose it will do to think
> of them as being a little like C++ templates, even though they're really
> not - more info at
> http://java.sun.com/developer/technicalArticles/J2SE/generics/ )
>
> I'm not sure if that's what the OP meant though, or how strong an
> example it is. :-)
Yes, exactly. From the developers perspective java generics and C++
templates are the same: a lot more complexity for debatable value. These
features allow library developers to invest a huge amount of time to
create an inflexible solution to a problem they think they understand.
But libraries win from being flexible and clear, able to adapt and be
adapted to now problems.
From the global view, should "we", the total development community,
invest in tools for making runtime type systems better or compile time
type systems better? I worked on compile-time system for years and came
to the conclusion that this was the wrong side. Unfortunately it gets
vastly more attention from academics, maybe because its 'benefits' can
be illustrated on a single page and don't need a complete implementation
and field testing.
>
> ~ Gijs
Martijn
> Yeah, I'm particularly concerned about 1) and 3).
> Option 2) is just a matter of fixing the stability issues.
I'm also wondering: why not remove MathML then, since that seems to be
used much less than XBL on the web, afaik?
Regards,
Martijn
Ray Kiddy
By the same logic, since not many people design rockets, let us stop
teaching rocket design in school. :-)
Ok, that's a reach. But there really needs to be a way to communicate
mathematically on the web. Right now, doing math on the web is kind of
like trying to do Ajax stuff with Netscape Navigator circa 1995, but it
will get better. MathML, IMHO, is going to be a part of that.
And why pick on MathML?
I think the MathML community would like for there to be infrastructure
in Firefox that allows people who want to use MathML to use it easily,
but makes no demands on the system otherwise. Is there any reason this
goal is incompatible with something that Firefox wants to do?
Also, my understanding is that MathML and XBL are very different, so why
bring up apples when there is a question about oranges?
- ray
Benjamin Smedberg
well...
* MathML is a complete specification that we've supported in the past
* We don't know exactly how much it's used on the web, but we know it's a
driver for adoption in a small circle of mathematics courses and the
academic community
We did seriously discuss whether fixing MathML for Firefox 3 was worth the
effort, and decided that it was.
--BDS
Martijn
> Martijn wrote:
> > On 12/20/07, Martijn <martijn...@gmail.com> wrote:
> >> Yeah, I'm particularly concerned about 1) and 3).
> >> Option 2) is just a matter of fixing the stability issues.
> >
> > I'm also wondering: why not remove MathML then, since that seems to be
> > used much less than XBL on the web, afaik?
> >
> > Regards,
> > Martijn
>
> By the same logic, since not many people design rockets, let us stop
> teaching rocket design in school. :-)
>
> Ok, that's a reach. But there really needs to be a way to communicate
> mathematically on the web. Right now, doing math on the web is kind of
> like trying to do Ajax stuff with Netscape Navigator circa 1995, but it
> will get better. MathML, IMHO, is going to be a part of that.
>
> And why pick on MathML?
Who needs MathML? Almost nobody.
Who needs XBL? A few people more than nobody, I think.
> I think the MathML community would like for there to be infrastructure
> in Firefox that allows people who want to use MathML to use it easily,
> but makes no demands on the system otherwise. Is there any reason this
> goal is incompatible with something that Firefox wants to do?
Security.
> Also, my understanding is that MathML and XBL are very different, so why
> bring up apples when there is a question about oranges?
They're not different in the fact that both need maintaining work at least.
Regards,
Martijn
> - ray
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Martijn Wargers - Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Chris Hofmann
on the Mathml discussion does anyone know more about something like
MathML in CSS, and if something like that might be possible in Mozilla and
the way we might provide support?
http://math.nist.gov/~BMiller/mathml-css/
http://www.stylusstudio.com/xmldev/200607/post80010.html
http://zvon.org/xxl/MathML/Output/index.html
http://lists.xml.org/archives/xml-dev/200607/msg00018.html
something like that might make it possible to get rid of the native MathML code (and any associated security risk, and bloat), but leverage existing (and maybe some new?) CSS support to provide the feature. That might be a cool way to do things if some one could step up to making the development, integration and testing work happen.
-chofmann
Martijn wrote:
On 1/9/08, Ray Kiddy <r...@ganymede.org> wrote:
Martijn wrote:On 12/20/07, Martijn <martijn...@gmail.com> wrote:Yeah, I'm particularly concerned about 1) and 3). Option 2) is just a matter of fixing the stability issues.I'm also wondering: why not remove MathML then, since that seems to be used much less than XBL on the web, afaik? Regards, MartijnBy the same logic, since not many people design rockets, let us stop teaching rocket design in school. :-) Ok, that's a reach. But there really needs to be a way to communicate mathematically on the web. Right now, doing math on the web is kind of like trying to do Ajax stuff with Netscape Navigator circa 1995, but it will get better. MathML, IMHO, is going to be a part of that. And why pick on MathML?
Who needs MathML? Almost nobody. Who needs XBL? A few people more than nobody, I think.I think the MathML community would like for there to be infrastructure in Firefox that allows people who want to use MathML to use it easily, but makes no demands on the system otherwise. Is there any reason this goal is incompatible with something that Firefox wants to do?Security.
Also, my understanding is that MathML and XBL are very different, so why bring up apples when there is a question about oranges?
They're not different in the fact that both need maintaining work at least. Regards, Martijn
Chris Hofmann
an one more link on how opera is working on a solution like this.,
http://dev.opera.com/articles/view/can-kestrels-do-math-mathml-support-in/
-chofmann
Chris Hofmann wrote:
on the Mathml discussion does anyone know more about something like
MathML in CSS, and if something like that might be possible in Mozilla and
the way we might provide support?
http://math.nist.gov/~BMiller/mathml-css/
http://www.stylusstudio.com/xmldev/200607/post80010.html
http://zvon.org/xxl/MathML/Output/index.html
http://lists.xml.org/archives/xml-dev/200607/msg00018.html
something like that might make it possible to get rid of the native MathML code (and any associated security risk, and bloat), but leverage existing (and maybe some new?) CSS support to provide the feature. That might be a cool way to do things if some one could step up to making the development, integration and testing work happen.
-chofmann
Martijn wrote:
On 1/9/08, Ray Kiddy <r...@ganymede.org> wrote:
Martijn wrote:On 12/20/07, Martijn <martijn...@gmail.com> wrote:Yeah, I'm particularly concerned about 1) and 3). Option 2) is just a matter of fixing the stability issues.I'm also wondering: why not remove MathML then, since that seems to be used much less than XBL on the web, afaik? Regards, MartijnBy the same logic, since not many people design rockets, let us stop teaching rocket design in school. :-) Ok, that's a reach. But there really needs to be a way to communicate mathematically on the web. Right now, doing math on the web is kind of like trying to do Ajax stuff with Netscape Navigator circa 1995, but it will get better. MathML, IMHO, is going to be a part of that. And why pick on MathML?
Who needs MathML? Almost nobody. Who needs XBL? A few people more than nobody, I think.I think the MathML community would like for there to be infrastructure in Firefox that allows people who want to use MathML to use it easily, but makes no demands on the system otherwise. Is there any reason this goal is incompatible with something that Firefox wants to do?Security.
Also, my understanding is that MathML and XBL are very different, so why bring up apples when there is a question about oranges?
They're not different in the fact that both need maintaining work at least. Regards, Martijn
- ray _______________________________________________ dev-planning mailing list dev-pl...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-planning
Boris Zbarsky
> I'm also wondering: why not remove MathML then, since that seems to be
> used much less than XBL on the web, afaik?
I'm not sure why you think it's used less. I've seen a fair amount of
use of MathML recently, in certain circles. I've seen no use of XBL
that wasn't braindead (some of the ad servers out there use it for no
good reason; just attaching a binding with no implementation and content
being just <children/>).
Past that, though, we're not talking about "removing" XBL. We're going
to provide the same functionality with XBL2. Until that happens, XBL1
is not going anywhere, clearly.
And all that said, removing MathML was pretty seriously considered for
Firefox 3. One reason it stayed is that it's in line with that little
"choice and innovation" bit in the Mozilla Foundation statement of
principles. So is a behavior-binding language. But the specific XBL1
syntax and processing model is not really something that supports those
principles any better than the XBL2 processing model, as things stand.
-Boris
Robert O'Callahan
> On 1/9/08, Ray Kiddy <r...@ganymede.org> wrote:
> > Also, my understanding is that MathML and XBL are very different, so why
> > bring up apples when there is a question about oranges?
>
> They're not different in the fact that both need maintaining work at least.
One big difference is that XBL messes with our content and layout
internals in very deep and complex ways. MathML doesn't.
Rob
Robert O'Callahan
stripping it down to just the stuff which can be done with CSS (or a
slight extension of CSS). It also means that you give up on all the
advanced math layout logic that rbs and others implemented to get our
MathML output looking about as nice as TeX, which is the standard most
MathML users expect. It's a good low-footprint solution, but it's
definitely a second-class solution.
Just last night I landed a big patch that fixes the biggest security
issues in MathML. Karl has done a ton of work to fix other issues. I
think MathML will be in a pretty good state in FF3 in both
functionality and security. We've done the work, Karl is up to speed
as the new MathML maintainer, we might as well carry on with our first-
class solution.
If the "MathML in CSS profile" becomes popular on the Web, more
popular than full MathML, then we can drop our implementation. But I
think the market should choose.
Rob
David Mandelin
> Gijs Kruitbosch wrote:
>> Mike Schroepfer wrote:
>>>
>>>> Both Java and Javascript added more typing after they were widely
>>>> considered to be productive systems while languages with strong
>>>> typing from Day One are never heard of again. Accident? Perhaps.
>>>
>>> Er?
>>>
>>> Java first edition published 1996: "Java is a strongly typed language,"
>>>
>>> http://java.sun.com/docs/books/jls/first_edition/html/4.doc.html#95845
>>>
>>> Did you mean something else?
>
> Yes, I should know better than use "strong typing".
Indeed. :-)
>> Well, one thing that Java did add later (only comparatively recently,
>> in fact) is generics, as compiletime substitute for the runtime
>> casting that everyone had been using before. [snip]
>
> Yes, exactly. From the developers perspective java generics and C++
> templates are the same: a lot more complexity for debatable value. These
> features allow library developers to invest a huge amount of time to
> create an inflexible solution to a problem they think they understand.
> But libraries win from being flexible and clear, able to adapt and be
> adapted to now problems.
I, too, haven't yet found a reason to be excited about Java Generics.
> From the global view, should "we", the total development community,
> invest in tools for making runtime type systems better or compile time
> type systems better? I worked on compile-time system for years and came
> to the conclusion that this was the wrong side. Unfortunately it gets
> vastly more attention from academics, maybe because its 'benefits' can
> be illustrated on a single page and don't need a complete implementation
> and field testing.
I'm glad you raised this issue. I've actually had lots of discussions
with academics on this question, but as you point out, it would be
incredibly hard to write a paper about it. But I think enough of them
would be perfectly happy to work on untyped languages if they had a list
of tractable yet interesting problems.
My take from those discussions, and also discussions with engineers, is
that untyped languages (my term for JS/Python/Perl/etc) are really good
for small teams. For large teams, typed languages (Java/C++/ML/etc) seem
to be better because the compiler forces programmers to use a certain
level of documentation and verification (the types). The smaller points
are that it's easier to make a typed language run fast, and that it also
seems large projects tend to benefit more from types.
If I were deciding where JS will go next, I'd want to know what kinds of
programs people are writing and in what kinds of teams. In the early
days, I'd bet there were a lot of small teams, small programmers, and
noob coders, and so untyped was the perfect match. Today, I don't
know--it seems there is some pretty big stuff in JS now.
I'm curious about your own experience that led you to think typed
languages (or "compile-time type systems") are really the wrong way.
Would you like to elaborate?
--
Dave Mandelin
Robert O'Callahan
you were running FF you usually needed to download special fonts to
see anything. With Karl's work in FF3, plus the availability (finally)
of the AMS STIX fonts which are quite free, things have changed; we're
able to use math fonts that most Windows and Mac users already have
installed, and if Linux distros start shipping STIX, most Linux users
too, so MathML will work out of the box for most users. With that,
plus our growing market share, we could see an increase in MathML
usage.
Rob
Robert O'Callahan
implementation for now.
On Jan 10, 2008 9:20 AM, Martijn <martijn...@gmail.com> wrote:
> Hi Chris,
>
> Karl and Robert are working on a bunch of MathMl bugs that are
> currently there, they might be interested in this.
> They also might be able to answer the question(s) in your previous mail.
>
> Regards,
> Martijn
>
> On 1/9/08, Chris Hofmann <chof...@meer.net> wrote:
> >
> >
> > an one more link on how opera is working on a solution like this.,
> >
> http://dev.opera.com/articles/view/can-kestrels-do-math-mathml-support-in/
> >
> > -chofmann
> >
> > Chris Hofmann wrote:
> >
> > on the Mathml discussion does anyone know more about something like
> > MathML in CSS, and if something like that might be possible in Mozilla
> and
> > the way we might provide support?
> >
> > http://math.nist.gov/~BMiller/mathml-css/<http://math.nist.gov/%7EBMiller/mathml-css/>
> > http://www.stylusstudio.com/xmldev/200607/post80010.html
> > http://zvon.org/xxl/MathML/Output/index.html
> > http://lists.xml.org/archives/xml-dev/200607/msg00018.html
> >
> > something like that might make it possible to get rid of the native
> MathML
> > code (and any associated security risk, and bloat), but leverage
> existing
> > (and maybe some new?) CSS support to provide the feature. That might
> be a
> > cool way to do things if some one could step up to making the
> development,
> > integration and testing work happen.
> >
> > -chofmann
> >
> > Martijn wrote:
> > On 1/9/08, Ray Kiddy <r...@ganymede.org> wrote:
> >
> >
> > Martijn wrote:
> >
> >
> > On 12/20/07, Martijn <martijn...@gmail.com> wrote:
> >
> >
> > Yeah, I'm particularly concerned about 1) and 3).
> > Option 2) is just a matter of fixing the stability issues.
> >
> > I'm also wondering: why not remove MathML then, since that seems to be
> > used much less than XBL on the web, afaik?
> >
> > Regards,
> > Martijn
> >
> > By the same logic, since not many people design rockets, let us stop
> > teaching rocket design in school. :-)
> >
> > Ok, that's a reach. But there really needs to be a way to communicate
> > mathematically on the web. Right now, doing math on the web is kind of
> > like trying to do Ajax stuff with Netscape Navigator circa 1995, but it
> > will get better. MathML, IMHO, is going to be a part of that.
> >
> > And why pick on MathML?
> >
> > Who needs MathML? Almost nobody.
> > Who needs XBL? A few people more than nobody, I think.
> >
> >
> >
> > I think the MathML community would like for there to be infrastructure
> > in Firefox that allows people who want to use MathML to use it easily,
> > but makes no demands on the system otherwise. Is there any reason this
> > goal is incompatible with something that Firefox wants to do?
> >
> > Security.
> >
> >
> >
> > Also, my understanding is that MathML and XBL are very different, so
> why
> > bring up apples when there is a question about oranges?
> >
> > They're not different in the fact that both need maintaining work at
> least.
> >
> > Regards,
> > Martijn
> >
> >
> >
> > - ray
> > _______________________________________________
> > dev-planning mailing list
> > dev-pl...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-planning
> >
> >
> >
> >
> > ________________________________
> >
> > _______________________________________________
> > dev-planning mailing list
> > dev-pl...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-planning
> >
> >
>
>
> --
> Martijn Wargers - Help Mozilla!
> http://weblogs.mozillazine.org/qa/
> http://wiki.mozilla.org/Mozilla_QA_Community
> irc://irc.mozilla.org/qa - /nick mw22
>
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
Martijn
Karl and Robert are working on a bunch of MathMl bugs that are
currently there, they might be interested in this.
They also might be able to answer the question(s) in your previous mail.
Regards,
Martijn
On 1/9/08, Chris Hofmann <chof...@meer.net> wrote:
>
>
> an one more link on how opera is working on a solution like this.,
> http://dev.opera.com/articles/view/can-kestrels-do-math-mathml-support-in/
>
> -chofmann
>
> Chris Hofmann wrote:
>
> on the Mathml discussion does anyone know more about something like
> MathML in CSS, and if something like that might be possible in Mozilla and
> the way we might provide support?
>
> http://math.nist.gov/~BMiller/mathml-css/
> http://www.stylusstudio.com/xmldev/200607/post80010.html
> http://zvon.org/xxl/MathML/Output/index.html
> http://lists.xml.org/archives/xml-dev/200607/msg00018.html
>
> something like that might make it possible to get rid of the native MathML
> code (and any associated security risk, and bloat), but leverage existing
> (and maybe some new?) CSS support to provide the feature. That might be a
> cool way to do things if some one could step up to making the development,
> integration and testing work happen.
>
> -chofmann
>
> Martijn wrote:
> On 1/9/08, Ray Kiddy <r...@ganymede.org> wrote:
>
>
> Martijn wrote:
>
>
> On 12/20/07, Martijn <martijn...@gmail.com> wrote:
>
>
> Yeah, I'm particularly concerned about 1) and 3).
> Option 2) is just a matter of fixing the stability issues.
>
> I'm also wondering: why not remove MathML then, since that seems to be
> used much less than XBL on the web, afaik?
>
> Regards,
> Martijn
>
> By the same logic, since not many people design rockets, let us stop
> teaching rocket design in school. :-)
>
> Ok, that's a reach. But there really needs to be a way to communicate
> mathematically on the web. Right now, doing math on the web is kind of
> like trying to do Ajax stuff with Netscape Navigator circa 1995, but it
> will get better. MathML, IMHO, is going to be a part of that.
>
> And why pick on MathML?
>
> Who needs MathML? Almost nobody.
> Who needs XBL? A few people more than nobody, I think.
>
>
>
> I think the MathML community would like for there to be infrastructure
> in Firefox that allows people who want to use MathML to use it easily,
> but makes no demands on the system otherwise. Is there any reason this
> goal is incompatible with something that Firefox wants to do?
>
> Security.
>
>
>
> Also, my understanding is that MathML and XBL are very different, so why
> bring up apples when there is a question about oranges?
>
Mike Shaver
> Just last night I landed a big patch that fixes the biggest security
> issues in MathML. Karl has done a ton of work to fix other issues. I
> think MathML will be in a pretty good state in FF3 in both
> functionality and security. We've done the work, Karl is up to speed
> as the new MathML maintainer, we might as well carry on with our first-
> class solution.
>
> If the "MathML in CSS profile" becomes popular on the Web, more
> popular than full MathML, then we can drop our implementation. But I
> think the market should choose.
I wonder how many of the gaps in CSS capabilities would be useful to
non-MathML scenarios. My ardent desire to see XUL become XBL wrapping
HTML+CSS.NEXT+JS is well-known, and I wonder if expanding CSS to make
the stretching and alignment capabilities from MathML more widely
available would be similarly nice.
Mike
John J Barton
> My take from those discussions, and also discussions with engineers, is
> that untyped languages (my term for JS/Python/Perl/etc) are really good
> for small teams. For large teams, typed languages (Java/C++/ML/etc) seem
> to be better because the compiler forces programmers to use a certain
> level of documentation and verification (the types).
I don't know what to make of this, because JS and Perl don't make any
sense without the C++/Java layers that enable them and conversely if all
the web had to be developed with C++ and Java we'd still be talking
about CORBA and gopher. It seems like the largest teams use a
combination of languages and esp. multiple runtimes. eg Netscape/Mozilla.
>
> I'm curious about your own experience that led you to think typed
> languages (or "compile-time type systems") are really the wrong way.
> Would you like to elaborate?
Type systems are great when used in moderation. I think that Java and
Javascript hit the sweet spot in allowing some types but not insisting
that types be used for everything. (And really my point is about where
to focus future work, not on good vs bad)
If you want to see what is possible with the C++ type system and
templates, please buy our book:
Scientific and Engineering C++: An Introduction with Advanced Techniques
and Examples by John J. Barton and Lee R. Nackman
See especially part III.
John.
>
> --
> Dave Mandelin
Myk Melez
> I've seen no use of XBL
> that wasn't braindead (some of the ad servers out there use it for no
> good reason; just attaching a binding with no implementation and content
> being just <children/>).
Perhaps this defeats some ad-blocking software?
-myk
Boris Zbarsky
> Perhaps this defeats some ad-blocking software?
Oh, interesting. It might do that for extensions that bind XBL to do
the ad blocking and do so in the UA stylesheet without !important.
Not exactly a use I'm worried about keeping working, to be honest. ;)
-Boris
David Mandelin
> David Mandelin wrote:
> > My take from those discussions, and also discussions with engineers, is
>> that untyped languages (my term for JS/Python/Perl/etc) are really
>> good for small teams. For large teams, typed languages
>> (Java/C++/ML/etc) seem to be better because the compiler forces
>> programmers to use a certain level of documentation and verification
>> (the types).
>
> I don't know what to make of this, because JS and Perl don't make any
> sense without the C++/Java layers that enable them and conversely if all
> the web had to be developed with C++ and Java we'd still be talking
> about CORBA and gopher. It seems like the largest teams use a
> combination of languages and esp. multiple runtimes. eg Netscape/Mozilla.
I don't disagree, although *I* don't know what to make of your point
that languages that aren't C are all implemented in C--that's a
technical detail and not important to most users.
>> I'm curious about your own experience that led you to think typed
>> languages (or "compile-time type systems") are really the wrong way.
>> Would you like to elaborate?
>
> Type systems are great when used in moderation. I think that Java and
> Javascript hit the sweet spot in allowing some types but not insisting
> that types be used for everything. (And really my point is about where
> to focus future work, not on good vs bad)
>
> If you want to see what is possible with the C++ type system and
> templates, please buy our book:
>
> Scientific and Engineering C++: An Introduction with Advanced Techniques
> and Examples by John J. Barton and Lee R. Nackman
>
> See especially part III.
Well, now I'm really confused. Reading your earlier comments I thought
you were arguing that the ES4 type system was too much typing and was a
bad thing, and not a good place to focus future work. And I thought your
comment just before this one implied you didn't like C++ templates. I
guess not.
Dave
John J Barton
We're pretty far from the orginal topic...
>
> Well, now I'm really confused. Reading your earlier comments I thought
> you were arguing that the ES4 type system was too much typing and was a
> bad thing, and not a good place to focus future work.
Yes, that is what I think, and my opinion is based on quite a lot of
experience with C++ templates. One can do lots of amazing and cool
things with these type systems. It's fun. But after pushing it hard I
came the conclusion that the effort to develop, support, and document
these kinds of type system features is poor investment relative to
runtime systems features. Very few developers benefit from advanced
type systems and the benefit is mixed. Almost all developers benefit
from better error recovery, faster dev turnaround, more correct and
complete environmental information and so on.
Hope this is clearer,
John.
fantasai
The CSSWG has a discussion about this approximately once a year (in a
joint meeting with the MathML WG). Some things seem like they'd be useful
elsewhere, others seem pretty specialized. We haven't done much work on
it though. The MathML WG posted a list of things they want here:
http://lists.w3.org/Archives/Public/www-style/2007Nov/0081.html
Note that rendering MathML with CSS currently requires a lot of extra,
otherwise unnecessary markup in the MathML -- i.e. your MathML needs to
be specially-written for a CSS implementation.
~fantasai