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)