Gecko/Toolkit/Core 1.9.1 cycle for non-FF apps?
Robert Kaiser
When looking at the current state of Gecko, the toolkit and "core" code
shared between multiple Mozilla applications, it becomes pretty clear
that 1.9 will be in a good shape for a Firefox 3 release, but just not
quite in the shape for other Mozilla-based applications to do their
releases from, mostly because of small problems, for which the patches
are too risky to take that late in the Firefox cycle though.
While we all understand that Firefox is our prime application and don't
want to induce unnecessary risk in the development of its nearing
release, it would be good if other Mozilla-based apps would have a
common base from which they can do their releases, which are probably
arriving quite a bit later than FF3 and 1.9 finals.
SeaMonkey 2 is slowly nearing an alpha, without specific targets for a
final, MailCo is just starting to plan what Thunderbird 3 should be
like, the calendar team has not even started to really work on 1.9-based
code yet, Camino is still based on xpfe to a certain part, not sure what
plans for applications not hosted on mozilla.org are - what we all have
in common is that we are very much in a different state than Firefox,
which is in the final stages of the release cycle.
Issues like bug 396519 or bug 407725 (or others on
<https://bugzilla.mozilla.org/showdependencytree.cgi?id=398751>) are
things that come up in daily testing and developing new features for the
new, 1.9-based versions of our applications - I'm pretty sure the other
app teams run into similar problems. Those are often issues that don't
look too large and have fixes that are not entirely large, but might be
risky, esp. when trying to stabilize a multi-million-download web
browser like Firefox and so got or get closed out of the 1.9 cycle.
If we would branch off 1.9.0 at the time of RCs for FF3 and leave the
CVS trunk under tight control, needing approvals but taking such
contained but higher-risk fixes (no really large changes, probably also
no real feature additions), we could make it grow into a base that
better fits our applications than 1.9.0 might by itself. We can version
this as 1.9.1 logically.
I wouldn't request heavy development to be seen there, and no commitment
of the FF or even toolkit team to do much work by themselves there, as
long as we get reviews and approvals (if feasible) for patches done by
"our" people to land there and get fixes from the 1.9.0 branch
landed/merged there as well. I understand this will be the end of CVS
work, but from what I hear, Mozilla2 is far from ready to have us base
our work on it (apart from the question of our future repositories).
Would this be something that can be done? As said, it's not about a
full-fledged 1.9.1 release, it's about making it something like a 1.9+
that is a better base for non-FF aps than 1.9 itself. FF can do a point
release based on this, but doesn't need to, that's completely up to
their managers - I just think it would be bad if SeaMonkey and others
would come to the conclusion that we need to have several forks of
toolkit code or features just because of a small collection of things
that we badly need but are too risky to still go into the 1.9 release.
Robert Kaiser
bre...@mozilla.org
just fixing things (compatibly) on the trunk after 1.9 and Firefox 3
go onto a branch. It's not clear that they will go on a branch this
time, but something has to capture the state of CVS, even if it's a
static tag sufficient to branch from later. Whatever we do, the 1.x.y
rule that APIs don't change still holds. So if you are trying to fix
some gnarly bfcache/docshell/shist bug, you may have to add an
interface on the side.
How is this different in kind from the last N times we've done main-
app(s) + Gecko releases as a tagged Mozilla milestone, and then SM and
other apps have followed? Maybe it's just different in the degree of
bugs?
/be
Boris Zbarsky
> Since you're not nearly ready to ship, there's no obvious problem with
> just fixing things (compatibly) on the trunk after 1.9 and Firefox 3
> go onto a branch.
> So if you are trying to fix
> some gnarly bfcache/docshell/shist bug, you may have to add an
> interface on the side.
I'm not sure that would do the trick in the case of the bfcache bugs; the
fundamental eviction algorithm bfcache uses is wrong in some ways and would need
to be fixed to fix some crashes. At the same time, that's a scary change that
Firefox might not want (probably doesn't want) on a release branch. Which
brings us back to multiple release branches...
I'll let KaiRo speak for the rest; he's more up on it than I am.
bre...@mozilla.org
Multiple release branches are not unknown. But let's focus on the
limits of API compatibility. If there's really no way to graft a new
ugly-named interface on the side of a module and use a better eviction
alg without keeping compatibility, I'd be surprised.
To answer Standard8's question: no, we don't always know if a bug can
be fixed compatibly. But it almost always can -- software is like
that. Security bugs that are inherent to the entire feature may mean
we just turn something off, or shrink a whitelist. That happens but
rarely.
It's good to be concrete, since you can borrow a lot of trouble with
"what if?" scenarios.
Also, all platforms have limited test coverage and a flagship app or
set of apps. They therefore have bugs that others find later.
Standard8's asking for fixes before shipping, at the limit, is
utopian. We can't find those bugs without shipping, or waiting so long
Firefox loses. That's not going to happen.
Shaver and Boris are right about the costs and huge benefits of
testing. On that front, we so much better off in large part due to
Sayre's efforts that I want to thank him, lest people think I'm mad at
him or something. I value careful argument and calm discourse, and I
think that bug was mishandled -- but that stuff happens, and the big
picture is that our platform pretensions have been real only to the
extent that our testing story has improved.
XUL and XBl are still weak spots there.
/be
Robert Kaiser
> If there's really no way to graft a new
> ugly-named interface on the side of a module and use a better eviction
> alg without keeping compatibility, I'd be surprised.
OK, I'm sold. I'll advise people in the SeaMonkey team to just get
things done in a way that we can get something worth shipping to users,
and forget about improving the platform. Obviously it's not possible to
help there, so just forget it. If we hit some wall, I'll encourage
people to fork the code and hack something up on our that works for what
we need and ignore the larger community. We have good and thorough
reviews, that should be enough. Maybe Someone (TM) from the platform
community will later take the hassle to port back all our improvements,
but we shouldn't care. Hell, that would be encouraging openness and
interoperability, nothing we can ship a product from. Let's stick to our
main priority of getting something shipped, everything else can wait. I
now agree that Firefox development makes a good role model.
Or did I misunderstand something here?
Robert Kaiser
Boris Zbarsky
>> If there's really no way to graft a new
>> ugly-named interface on the side of a module and use a better eviction
>> alg without keeping compatibility, I'd be surprised.
>
> Or did I misunderstand something here?
I think you did. Brendan seems to be proposing that we add an API to bfcache in
a point release before Seamonkey ships that does exactly what you want out of
it, without changing any of the bfcache code that normally runs during
back/forward navigation (thus minimizing risk).
-Boris
P.S. On a separate note, I'm a little confused by the "patch has been waiting
for review forever" complaint. There should have been no surprise here--I said
in the bug back in early November that I would not be able to get to the review
until sometime in the spring. No one ever bothered to switch the review request
to a different active docshell reviewer (biesi doesn't read bugmail), mention
the problem to drivers, or any of the other actions that should be taken when
review resources need to be rounded up. Of course the fact that we just don't
have much in the way of active docshell reviewers is a major problem...
bre...@mozilla.org
> Or did I misunderstand something here?
Yes. Why?
/be
Robert Kaiser
OK, good. I probably just wanted to be sure of that. :)
Robert Kaiser
Robert Kaiser
> Of course the fact that we just don't have much
> in the way of active docshell reviewers is a major problem...
I guess so.
Robert Kaiser
Mark Banner
> Also, all platforms have limited test coverage and a flagship app or
> set of apps. They therefore have bugs that others find later.
> Standard8's asking for fixes before shipping, at the limit, is
> utopian. We can't find those bugs without shipping, or waiting so long
> Firefox loses. That's not going to happen.
I never asked for that or meant to imply it.
Standard8
Justin Wood (Callek)
potential Firefox branching and a creation of an approval1.9.1 flag, as
relating to an l10n thread), that we may simply have a new approval model.
Is this specifically approvals for "1.9.1" as we have been discussing
here, and thus we expect "1.9.1" to happen in some form or another (if
so, what).
Or is it more like 1.9.0.1 as a security-only release (to correspond
with Firefox security releases as in the past)?
--
~Justin Wood (Callek)