Thoughs on 1.9, 1.9.1, and 2
Vladimir Vukicevic
happens when 1.9 is done: do we go full-bore on 2? Do we plan for an
interim release? Do we have a way of fixing small polish/regression
bugs that we weren't able to get to 1.9 before the next major release?
The main thing I'll assert here is that I think it is vitally
important that the entire engineering team commits fully to work that
will benefit whatever initial release "Mozilla 2" becomes: being able
to make API-breaking changes, architectural improvements, potentially
doing some of the large changes such as XPCOM GC, Tamarin, etc.
However, I believe that there is a large set of changes and features
that are important for us to work on that don't require or impact Moz
2 at all; for example (from areas that I'm most familiar with),
<video> support, improvements to SVG, downloadable fonts, CSS
border-image, etc. So, I'd like to propose the following plan:
<http://people.mozilla.com/~vladimir/misc/branch-moz2.svg>
I'm pretty sure the things in green and orange are not controversial;
we will obviously do security fixes for issues as they come up for
1.9.0.x, mobile work will be ongoing with 1.9, and for Moz 2, all
those things I named above will be happening.
The items in yellow are, I think, what a lot of people are pondering
right now. I think that there is room for a 1.9.1 release on a very
quick cycle -- 6 months probably at the longest. I would suggest that
for regular 1.9.0.x maintenance releases, in addition to taking
security fixes, we also take well-tested and low-impact regression
fixes, and possibly very small isolated features. Both of these
should have no impact on Mozilla 2 to be worked on -- that is, they
should be equally relevant to 1.9 as they would to Moz 2. (For
example, CSS border-image would be a feature that I think could go
into a 1.9.0.x release.)
1.9.1 would include feature work that is of more moderate size, but
again, that applies equally to 1.9 and 2. <video> is a good example;
the compositor work is not. Some of these features will definitely
have overhead in ensuring that they fit in both 1.9 and Moz 2
codebase; if that overhead becomes high, the feature should be cut
from 1.9.1. I've also placed additional work for mobile in the 1.9.1
column; it seems natural that any mobile development will (at some
point) want to have a "release" branch, and not just be 1.9.0.x +
various patches.
There are costs with doing the 1.9.1 release: mainly triage, build,
and QA work, so it's not entirely free. Developer costs would also
exist, but I think that if they are manageable, doing a 1.9.1 release
would be valuable. Much like features for which developer overhead
becomes too high for 1.9 and Moz 2 implementation, 1.9.1 should be an
opportunistic release: I think we should plan on it, but if it doesn't
look like we can deliver a compelling 1.9.1 within some small number
of months after 1.9 release, we should cut 1.9.1 (and the associated
release overhead) and focus entirely on Mozilla 2.
Incidentally, this is speaking entirely from a platform point of view;
I think a 1.9.1 would be valuable both for the Firefox front end (for
all the front end work that we didn't have time for in Fx 3) and for
other applications that build on top of Gecko (both for taking
advantage of new Gecko 1.9 features, and for fixing
application-specfici regressions).
Thoughts?
- Vlad
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
Mike Beltzner
Lots!
I think you've captured things well from a platform development
perspective, in terms of making sure that if we dare to once again split
our focus between three branches (1.9.0.x / 1.9 / moz2) we do so knowing
full well how that will affect the quality and speed at which we can
deliver products. And actually, we shouldn't neglect to realize that
until at least 6 months after the release of Firefox 3 we're actually
talking about keeping four branches (1.8.1.x / 1.9.0.1 / 1.9 / moz2) in
development.
From a product delivery / front-end side of things, though, I want to
make sure that we evaluate the worth of a 1.9.1 release based on the
opportunities and costs involved. To do this I'd love to get a set of
guesses at timelines sketched out to help us decide when we'd need to be
pushing out a 1.9.1-based product in order to be useful to our various
consumers (users, website authors, add-on authors / platform consumers)
and whether or not we can deliver the content required to make that
release meaningful. I think that would help answer some of the scoping
questions you raise.
My proposal for how to do this would be to try and coarsely describe the
various areas of development (as a first try: performance, platform
capability, platform architecture, security, UI feature development) and
build roadmaps that take into account where we want to take things in
the near and long term futures, and where the various competitor and
community ecosystems are going in terms of standards, specifications,
etc. I'm not sure who the right people are to help, here, but I fear
that a lot of them are the same ones who are heads down working on
delivering Firefox 3.
Finally, while I'd encourage people looking at that thread to absolutely
start thinking about the points made, I don't think people should worry
about having to drop what they're doing to answer this post now, or to
answer these questions now. I definitely agree that we need to figure
out how and when we'll get those answers, but think that the best time
to target for that is "after RC1", at least :)
cheers,
mike
Stuart Parmenter
> I'm pretty sure the things in green and orange are not controversial;
> we will obviously do security fixes for issues as they come up for
> 1.9.0.x, mobile work will be ongoing with 1.9, and for Moz 2, all
> those things I named above will be happening.
>
I very strongly disagree with the idea of doing a 1.9.1 (at all) on a
short cycle. We should instead focus on doing a Mozilla 2 (all this
means is breaking APIs) on a short schedule instead. We can do the
same set of work you suggest and break a few APIs. This means we no
longer have to keep the same API compatibility promises we've made in
the past which are holding us back in many ways. I'm of the opinion
that we probably won't be able to land MMGC, Tamarin, etc in this
short time frame but that people should continue working on them.
I think we should be looking at more of a 12 month schedule. We
likely need that much time to get a compelling Firefox release out. I
also don't see any advantage to doing a 1.9.1 release. All I see is
it splitting up the team and requiring people working on 4 (1.9,
1.9.1, 2, 2.1?) releases simultaneously. It is hard enough to ship 1
release with everyone on board. Lets leverage the people we have and
focus on a solid release.
stuart
Robert Kaiser
> The main thing I'll assert here is that I think it is vitally
> important that the entire engineering team commits fully to work that
> will benefit whatever initial release "Mozilla 2" becomes
I guess you mean the platform developers only here, as from what I see,
Moz2 is not nearly fit for anything else than in-deep platform
development right now, and esp. not for anything else than Firefox on
top of it, as:
1) Most other apps are not even near to anything shippable on 1.9.
2) There's a lot in flux of what Moz2 will even look like.
3) any app code developed on top of current Moz2 probably needs to be
rewritten 2-3 times before the platform gets nearly usable.
4) The toolchain for apps outside mozilla-central is completely
unresolved, there isn't nearly a solution for this yet.
5) There's no guesstimate how long the Moz2 dev cycle could be, we might
not see a stable release in this century.
In that light, I think your proposal for 1.9.1 sounds reasonable, though
I know a certain amount of people starts to shudder when thinking we
might get a similar situation as for 1.7/1.8.0/1.8.1/1.9 parallel
development/maintenance.
Robert Kaiser
Mike Shaver
> I would suggest that
> for regular 1.9.0.x maintenance releases, in addition to taking
> security fixes, we also take well-tested and low-impact regression
> fixes, and possibly very small isolated features.
I don't think they need to be very small (and don't want to get into
fights about what "very small" is, much as I love a good fight), but I
do think they need to be isolated. And I won't settle for "possibly".
> Both of these
> should have no impact on Mozilla 2 to be worked on -- that is, they
> should be equally relevant to 1.9 as they would to Moz 2. (For
> example, CSS border-image would be a feature that I think could go
> into a 1.9.0.x release.)
I think we should do things that are 1.9.0.x-capable (meaning
well-scoped, additive, backward-compatible, isolated, have solid test
suites, cleanly object-detectable) and we should do things for Mozilla
2, but I don't think we should do platform features that are in the
middle. Mozilla 2 can't be an experimental playground, it needs to be
a place where things are pushed to product-quality completeness as
dominant model, so that we stay close to being ship-ready and don't
end up off in the weeds for 18, no 24, no 30 months trying to converge
on a product state.
> 1.9.1 would include feature work that is of more moderate size, but
> again, that applies equally to 1.9 and 2. <video> is a good example;
> the compositor work is not.
<video> in 1.9.0.x. Worker threads in 1.9.0.x. querySelector in
1.9.0.x. Content-exposed JSON in 1.9.0.x. Follow-on XS-XHR in
1.9.0.x. Compatible ES4 features that are spec-stable enough in
1.9.0.x. Scriptable plugin API features in 1.9.0.x. Cairo tracking
for perf and rendering quality in 1.9.0.x. SRP in 1.9.0.x.
Compositor in 2. XPCOMGC in 2. Tamarin-or-a-hand-drawn-facsimile in
2. A complete RDFectomy in 2. SVG architecture work for size and
speed in 2. Fixing file-launch and web-protocol integration to not
hurt, probably in 2, because I can't see doing it extension-compatibly
unless someone really leans into that test framework.
(And by "2" I mean "2 or later", not that I would block for all of those.)
I would much much rather trickle in capabilities along the 1.9.0.x
series as their ready than try to wrap them all up into a unified
middling-bang release. It lets us take features when they're ready,
reduces the risk of "I'll figure out that edge case when we get closer
to release" or "ah, since there's another 2 months until freeze, I'll
put in something else!".
Means we'd need a beta or Technology Preview channel for people to
test against, with these (isolated, remember) 1.9.0.x-grade features
promoted to them when they reached beta state. Well-understood
problem, I think.
> Incidentally, this is speaking entirely from a platform point of view;
> I think a 1.9.1 would be valuable both for the Firefox front end (for
> all the front end work that we didn't have time for in Fx 3) and for
> other applications that build on top of Gecko (both for taking
> advantage of new Gecko 1.9 features, and for fixing
> application-specfici regressions).
Firefox compat is a different calculus, I think: harder for the app to
do anything interesting without breaking extension compat; easy for it
to do a lot of stuff without breaking content compatibility.
Mike
Doug Turner
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Mike Shaver
> I agree with Mobile using a 1.9 CVS branch.
Is that because you've been having problems with Mercurial, or because
you want to be able to make possibly-destabilizing (and therefore
1.9.0.x-ineligible) changes? Why wouldn't you want to integrate early
and often, and get your test cases into the critical path for others
working on the core code?
Mike
Mike Connor
- Mike
----- Original Message -----
From: dev-planni...@lists.mozilla.org
<dev-planni...@lists.mozilla.org>
To: Vladimir Vukicevic <vlad...@pobox.com>
Cc: dev-pl...@lists.mozilla.org <dev-pl...@lists.mozilla.org>
Sent: Fri Mar 07 07:25:30 2008
Subject: Re: Thoughs on 1.9, 1.9.1, and 2
I agree with Mobile using a 1.9 CVS branch.
Benjamin Smedberg
* I am especially concerned about splitting our testing resources three
ways. Not just employed QA, but our nightly tester community is an
especially valuable resource. 1.9 didn't get much nightly testing for a long
time while 1.8.1 was going on, partly because of the places debacle.
* I think we should be more lenient about changing internal APIs in 1.9.0.x,
as I posted recently in dev.platform. This should make it easier to
integrate new content-facing features such as video/cross-site XHR, etc
directly into 1.9.0.x rather than an in-between spot
* Mozilla 2 is a chance to break APIs. It is not a place to take massive
instability. I think that, whatever schedule we pick, we should require
mozilla-central to be in a shippable state all the time.
** Unit testing certainly helps with this
** as well as a willingness to aggressively back out things as regressions
are found (no more half-baked threadmanager)
** So does the distributed-branching model: we have most of the
infrastructure in place now to produce builds, perftest, and unit-test
feature branches for long periods of time before they are merged
I think we come up with an arbitrary metric that mozilla-central is "21 days
from beta" all the time. I'm wondering if it's possible to introduce a
lightweight continuous-driving process which can keep us in a
constant-quality state and provoke the aggressive backouts needed to keep
quality.
The danger is this is that we'd never be able to land large features which
by their nature require more than 3 weeks of regression-fix time. Looking
back on 1.9 with the promise of better distributed-branches tooling, do you
think we could have landed cocoa widgets, cairo, places, threadmanager, or
the reflow branch with less than 3 weeks of regressions? Or that we will be
able to land XPCOMGC, (Tamarin) tracing, or compositor in 2.0 with less than
3 weeks of regressions?
If we can, then we can make decisions about when to ship much later than we
have... start doing work, and when the trunk seems suitably better than our
current release, decide that we're going to do the Firefox 4 beta in a
month, with another month of RCs for a total time-to-ship of 8 weeks.
--BDS
Doug Turner
On Mar 7, 2008, at 7:45 AM, Mike Shaver wrote:
> On Fri, Mar 7, 2008 at 10:25 AM, Doug Turner <doug....@gmail.com>
> wrote:
>> I agree with Mobile using a 1.9 CVS branch.
>
> Is that because you've been having problems with Mercurial, or because
> you want to be able to make possibly-destabilizing (and therefore
> 1.9.0.x-ineligible) changes? Why wouldn't you want to integrate early
> and often, and get your test cases into the critical path for others
> working on the core code?
>
> Mike
Mike,
We want to ship something this year. It looks like 1.9 is the vehicle
to do just that. Am I missing something?
Doug
Doug Turner
What purposes are you talking about?
On Mar 7, 2008, at 7:57 AM, Mike Connor wrote:
> I don't think that's a stated goal, or ideal for our purposes...
>
> - Mike
>
> ----- Original Message -----
> From: dev-planni...@lists.mozilla.org <dev-planni...@lists.mozilla.org
> >
> To: Vladimir Vukicevic <vlad...@pobox.com>
> Cc: dev-pl...@lists.mozilla.org <dev-pl...@lists.mozilla.org>
> Sent: Fri Mar 07 07:25:30 2008
> Subject: Re: Thoughs on 1.9, 1.9.1, and 2
>
> I agree with Mobile using a 1.9 CVS branch.
>
>
Doug Turner
the tools work, i do not care what the VCS is. I would like to stick
with CVS because everyone knows how to use it, but if mozilla is going
to switch, great.
Boris Zbarsky
> <video> in 1.9.0.x. Worker threads in 1.9.0.x. querySelector in
> 1.9.0.x. Content-exposed JSON in 1.9.0.x. Follow-on XS-XHR in
> 1.9.0.x. Compatible ES4 features that are spec-stable enough in
> 1.9.0.x. Scriptable plugin API features in 1.9.0.x. Cairo tracking
> for perf and rendering quality in 1.9.0.x. SRP in 1.9.0.x.
I'm assuming we're up for arguments about the suitability of some of these
(worker threads jumps out at me) for a stable release? I agree that some of
these others ought to be safe enough to add in a 1.9.0.x release, but see below.
If we do this sort of thing we'll need a much better testing (not just
automated, but user testing) and regression-fixing story than we've had with the
1.8.0 and 1.8.1 branches... but I'm assuming that's part of the plan anyway.
One issue I worry about here is that some of these changes could in fact affect
web compat. querySelector, ES4 things. They shouldn't, but I won't bet there
is NO site out there that uses a function called querySelector that they attach
to nodes. See the issues we ran into with getElementsByClassName, some of which
are still pending evangelism action. While we may be willing to take the
potential compat hit, it's worth checking on our various distributors (on Linux,
basically, since we do our own thing on Window/Mac). Are they willing to go
with that approach? Or are they going to start cherry-picking security fixes
but avoiding the feature ones? That's a path we'd all like to avoid, I think.
If we can swing it, I'd definitely prefer this approach to a 1.9.1 release,
because the things you list have vastly different development times. For
example, querySelector and a lot of the remaining CSS3 selectors can probably be
wrapped up in 2 weeks. I doubt <video> is that close to be being done, for example.
-Boris
Mike Shaver
> We want to ship something this year. It looks like 1.9 is the vehicle
> to do just that. Am I missing something?
Are you talking about a mobile-specific branch, or shipping off the
1.9 branch? We very much plan to ship off the 1.9 stream multiple
times this year, so that alone isn't reason enough to be on a
mobile-specific branch.
I haven't looked at the mobile roadmap to see what the disruptive
changes are, or what the level of confidence is tests to back up
whatever mobile-oriented changes land, so I don't know much about what
your other constraints are. Can you be more explicit?
Mike
Doug Turner
we are planning for this year doesn't require large changes on to
1.9. If we are wrong, we would switch over to Moz2.
Vladimir Vukicevic
BenjaminSmedberg <benj...@smedbergs.us> wrote:
> * Mozilla 2 is a chance to break APIs. It is not a place to take
> massive instability. I think that, whatever schedule we pick, we
> should require mozilla-central to be in a shippable state all the
> time.
I don't think there will be massive code/crashyness instability (I
agree with your "21 days from beta" suggestion), but there will be
massive platform API churn that people will be playing catchup to.
> Unit testing certainly helps with this
> as well as a willingness to aggressively back out things as
> regressions are found (no more half-baked threadmanager)
> ** So does the distributed-branching model: we have most of the
> infrastructure in place now to produce builds, perftest, and
> unit-test feature branches for long periods of time before they are
> merged
Yep, I think this is going to be key for anything we do, whether it's
1.9.0.x or 2.0 -- being able to test and produce builds from branches
is going to be essential. Maybe someone out there can cook up a
build-selector extension that will download and install a mar file
from a specific named build/branch, so that nightly users can switch
between these branches easily...
> The danger is this is that we'd never be able to land large features
> which by their nature require more than 3 weeks of regression-fix
> time. Looking back on 1.9 with the promise of better
> distributed-branches tooling, do you think we could have landed cocoa
> widgets, cairo, places, threadmanager, or the reflow branch with less
> than 3 weeks of regressions? Or that we will be able to land XPCOMGC,
> (Tamarin) tracing, or compositor in 2.0 with less than 3 weeks of
> regressions?
At least for cairo, back then, I don't think we could have. Today?
It could have been a lot better: we have a huge testing infrastructure
that didn't exist before. Just the reftests alone would've been
extremely helpful.
> If we can, then we can make decisions about when to ship much later
> than we have... start doing work, and when the trunk seems suitably
> better than our current release, decide that we're going to do the
> Firefox 4 beta in a month, with another month of RCs for a total
> time-to-ship of 8 weeks.
I don't know whether this would be possible in practice; it may be for
a Gecko/platform release, but I think the front end work is always
going to lag behind platform work (because they need the platform work
in place to take advantage of the new functionality, if it's front-end
visible).
Mike Shaver
> I'm assuming we're up for arguments about the suitability of some of these
> (worker threads jumps out at me) for a stable release? I agree that some of
> these others ought to be safe enough to add in a 1.9.0.x release, but see below.
Arguing about them seems inevitable, but building judgments of them
based on two-word descriptions is hopefully not inevitable. :)
> If we do this sort of thing we'll need a much better testing (not just
> automated, but user testing) and regression-fixing story than we've had with the
> 1.8.0 and 1.8.1 branches... but I'm assuming that's part of the plan anyway.
"Much better" lacks actionable detail, especially in concert with
"need" -- can you offer some specific states you think we would need
to be able to hit?
I think just having stuff beta in a tech-preview release sequence
would on its own increase the amount of test coverage dramatically,
and with isolated features the risk of one addition masking another's
badness gets pretty low.
> One issue I worry about here is that some of these changes could in fact affect
> web compat. querySelector, ES4 things. They shouldn't, but I won't bet there
> is NO site out there that uses a function called querySelector that they attach
> to nodes.
Yep, and I won't bet there are NO sites out there that weren't broken
by our jar: restrictions, etc. A tech-preview beta channel gives us a
way to get some soaking on these things, but perfection can't be the
criterion. There will be trade-offs here, and we'll have to make them
case-by-case.
> See the issues we ran into with getElementsByClassName, some of which
> are still pending evangelism action. While we may be willing to take the
> potential compat hit, it's worth checking on our various distributors (on Linux,
> basically, since we do our own thing on Window/Mac). Are they willing to go
> with that approach? Or are they going to start cherry-picking security fixes
> but avoiding the feature ones? That's a path we'd all like to avoid, I think.
That's a path I'd like to see the Linux distributors avoid, as well,
but I'm pretty sure they're interested in shipping Firefox, so I don't
think it's inevitable at all. We should figure out what's right for
our product first, and then we can see how that fits in with
companies' other products. (TBH, I have no idea what we're doing with
Linux builds these days; are we shipping the beta to people through
the channels we're expecting them to use for release? That's another
thread!)
> If we can swing it, I'd definitely prefer this approach to a 1.9.1 release,
> because the things you list have vastly different development times. For
> example, querySelector and a lot of the remaining CSS3 selectors can probably be
> wrapped up in 2 weeks. I doubt <video> is that close to be being done, for example.
I don't know what the situation is with <video>, but I suspect it
takes 2 weeks just to build a basic test suite for it (not enough to
ship, possibly enough to get it in the Tech Preview train).
Mike
Stuart Parmenter
> i am not expecting to be on a mobile-specific branch. Ideally, what
> we are planning for this year doesn't require large changes on to
> 1.9. If we are wrong, we would switch over to Moz2.
>
stuart
Mike Connor
Care to explain why?
That's basically a strategic decision that its better to wait an extra
year to ship something. I don't think they have any intention at all
of waiting that long, nor do I believe is it the right thing to do
with the mobile product...
-- Mike
Doug Turner
why?
is mozilla 2 going to be ready for people to ship off of in 6 or 9
months?
Boris Zbarsky
> Arguing about them seems inevitable, but building judgments of them
> based on two-word descriptions is hopefully not inevitable. :)
Of course. Any sort of argument would need to dig into details.
>> If we do this sort of thing we'll need a much better testing (not just
>> automated, but user testing) and regression-fixing story than we've had with the
>> 1.8.0 and 1.8.1 branches... but I'm assuming that's part of the plan anyway.
>
> "Much better" lacks actionable detail, especially in concert with
> "need" -- can you offer some specific states you think we would need
> to be able to hit?
Branch drivers need to be able to get resources committed to actually
fixing branch regressions. From what I'm seeing on branch right now,
the workflow often works like this:
1) A patch lands in a .x branch release. It causes a regression that's
not caught until the .x branch release ships. Sometimes not until the
.(x+n) release ships for n == 1 or 2.
2) The regression is marked blocking .(x+1) (or .(x+n+1), whatever).
3) The developer who caused the regression doesn't have time to work on
it due to other commitments or because he simply forgets to or whatever.
4) A few weeks before the branch release branch drivers mail out a
reminder to get patches in. Often enough, it's too late to get things
fixed on trunk (complete with the approval cycle), get bake time, and
get them on the branch at this point. But in any case, none of the
conditions listed in item 3 have changed.
5) The regression gets pushed out to the next branch release (with a
'?', sometimes, with a '+' other times).
Repeat steps 2-5 for several branch releases.
It seems that branch drivers don't actually have the ability to get
someone tasked with fixing a branch regression and are essentially
dependent on people cleaning up after themselves. If someone is either
unwilling or unable to do so, we get lossage. If we can change this
dynamic, we should.
The other possible issue is that it seems that we don't have that many
people using the branch nightlies... Or maybe they're not reporting
bugs. Or maybe those bugs are not ending up in the right places. But
the net effect is the .(x+n) effect described above. I might be wrong
on this, though; maybe it's just that we only regress very obscure
things on branch so that it's hard to catch them...
> I think just having stuff beta in a tech-preview release sequence
> would on its own increase the amount of test coverage dramatically
That would possibly address the second issue above, yes.
> and with isolated features the risk of one addition masking another's
> badness gets pretty low.
Yes, agreed.
> Yep, and I won't bet there are NO sites out there that weren't broken
> by our jar: restrictions, etc.
Sure. It's a matter of whether we _have_ to take the change (to protect
users, prevent bad PR, whatever) vs whether we'd kind of like to take
the change because it improves our platform... I don't think anyone was
that happy with the jar: fallout, we just couldn't think of a better way.
Ideally, we'd minimize the number of times web sites have to update to
deal with our releases, right?
> There will be trade-offs here, and we'll have to make them
> case-by-case.
Agreed.
> That's a path I'd like to see the Linux distributors avoid, as well,
> but I'm pretty sure they're interested in shipping Firefox, so I don't
> think it's inevitable at all.
I don't think it's inevitable either; I'm just suggesting that sounding
them out may give us more data on which to base this decision, if it's
data we want to consider. You argue that we shouldn't care about it.
That might be true; I'm not up on our relationship with the various
parties involved.
-Boris
Dan Mosedale
> Vladimir Vukicevic wrote:
>> The main thing I'll assert here is that I think it is vitally
>> important that the entire engineering team commits fully to work that
>> will benefit whatever initial release "Mozilla 2" becomes
>
> I guess you mean the platform developers only here, as from what I see,
> Moz2 is not nearly fit for anything else than in-deep platform
> development right now, and esp. not for anything else than Firefox on
> top of it, as:
>
>
> In that light, I think your proposal for 1.9.1 sounds reasonable, though
> I know a certain amount of people starts to shudder when thinking we
> might get a similar situation as for 1.7/1.8.0/1.8.1/1.9 parallel
> development/maintenance.
It feels to me like Thunderbird is in a similar spot: we're going to
want to be doing our next release off of something that's not Mozilla2,
whether that's 1.9.1 or just "trunk, but cut a release branch as late as
is reasonable". I agree with Robert, though, that attempting to
over-parallelize is fairly scary.
Having well-baked 1.9.1 tag would be ideal for Thunderbird, but if the
trunk continues to be highly stable, it's probably not necessary. I do
wonder how much of the trunk's stability has been a result of the fact
that we've been under driver control for quite a while. Maybe the
appropriate way to test and move forward post-1.9 would be to take it
out from driver control as a test, and see what happens, with the idea
of adding some control mechanism back in if necessary.
Dan
Dan Mosedale
> In article<hqCdnf8bvYGU9Eza...@mozilla.org>
> BenjaminSmedberg<benj...@smedbergs.us> wrote:
>
>> Unit testing certainly helps with this
>> as well as a willingness to aggressively back out things as
>> regressions are found (no more half-baked threadmanager)
>>
>> ** So does the distributed-branching model: we have most of the
>> infrastructure in place now to produce builds, perftest, and
>> unit-test feature branches for long periods of time before they are
>> merged
>
> Yep, I think this is going to be key for anything we do, whether it's
> 1.9.0.x or 2.0 -- being able to test and produce builds from branches
> is going to be essential. Maybe someone out there can cook up a
> build-selector extension that will download and install a mar file
> from a specific named build/branch, so that nightly users can switch
> between these branches easily...
Is the theory here that the reviewing will happen incrementally before
landing on the feature branches? Historically, some of the biggest pain
we've run into with feature branches has been reviewing them at the end
(both in terms of people finding time, and the impracticality of being
sufficiently thorough on something huge).
Dan
Mike Shaver
> Having well-baked 1.9.1 tag would be ideal for Thunderbird, but if the
> trunk continues to be highly stable, it's probably not necessary. I do
> wonder how much of the trunk's stability has been a result of the fact
> that we've been under driver control for quite a while. Maybe the
> appropriate way to test and move forward post-1.9 would be to take it
> out from driver control as a test, and see what happens, with the idea
> of adding some control mechanism back in if necessary.
I'd love to see us go from driver control to mochi control. No test,
no review, no commit. It'd take a lot of noise out of the system, and
make the end-game a lot less scary.
("Oh no! I have to think about how to test this feature! I might have
to write some code! Oh no!" Operators are standing by with crying
towels.)
Mike
(mochi, Tunit, reftest, whatever)
Benjamin Smedberg
> 1) Most other apps are not even near to anything shippable on 1.9.
What has this got do with the discussion? Should we not do moz2 because of
it? Or are you saying we *should* do 1.9.1 because of it? What's the
practical difference between the two, for these other apps?
> 2) There's a lot in flux of what Moz2 will even look like.
Do you mean the moz 2.0 platform release specifically, or what the general
roadmap is? I think the general roadmap is relatively clear:
* drop binary compatibility requirements with the mozilla 1.x series
* change APIs if needed... with care to preserve the JavaScript reflection
of APIs whenever possible
* work on major architectural changes:
** integration with Tamarin or at least a tracing JS engine
** XPCOMGC
** Compositor
** Maybe XBL2
** See the wiki
* keep mozilla-central stable all the time
> 3) any app code developed on top of current Moz2 probably needs to be
> rewritten 2-3 times before the platform gets nearly usable.
This is nonsense. App code written in JavaScript will probably need no, or
little revision for moz2. XBL bindings may need work, but we're going to try
to either have automated tools to rewrite from XBL1 to XBL2 or keep both
impls in parallel for a while to aid transition.
Code written in C++ will need to have the same automatic tranformations
applied to it that we apply to gecko itself, but the tools will be available
to do the transformations.
> 4) The toolchain for apps outside mozilla-central is completely
> unresolved, there isn't nearly a solution for this yet.
This is also nonsense. Pulling multiple codebases together and hooking them
up to the mozilla build is a problem that was solved over a year ago and
contributed back from the Songbird project. The fact that it's mercurial and
not CVS is a minor implementation detail.
Have you tried it, or are you just trying to lay a smokescreen to prevent
real work from getting done?
> 5) There's no guesstimate how long the Moz2 dev cycle could be, we might
> not see a stable release in this century.
Schrep's original post about the moz2 cycle, as well as followups on this
thread, should make it clear that the moz2 cycle will be driven by
continuous stability (and good tests).
--BDS
L. David Baron
> <video> in 1.9.0.x. Worker threads in 1.9.0.x. querySelector in
> 1.9.0.x. Content-exposed JSON in 1.9.0.x. Follow-on XS-XHR in
> 1.9.0.x. Compatible ES4 features that are spec-stable enough in
> 1.9.0.x. Scriptable plugin API features in 1.9.0.x. Cairo tracking
> for perf and rendering quality in 1.9.0.x. SRP in 1.9.0.x.
So it occurred to me with a full 40 minutes to spare before the
localization freeze that if this is the plan, some of these features
might need new strings. I'm landing one string for bug 75375 in a
few minutes.
If anyone else can think of the same issue for other potential
1.9.0.x features, well, you have 22 minutes left.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Robert O'Callahan
1) Regressions on the stable branch are poison. Yes, we'll have test
automation on the branch we never had before. Yes, we're talking about
isolated features. But they're not fully isolated; for example,
downloadable fonts will have to integrate with font selection (three
implementations of). New features create regression opportunities,
like it or not, and anything which cautions people against applying
minor updates is extremely bad for them and for us. So I strongly feel
we should minimize regression risk. (By the same argument I think we
should actually be more conservative about security fixes than we have
been on the 1.8.1 branch, by not taking patches for some of the more
obscure bugs.)
2) At least some of our consumers (e.g. Thunderbird, most non-Firefox
XUL apps, maybe mobile, probably Linux distros) will want to take
security and stability fixes but the argument for having them take new
platform features at the same time is weak. We should offer them
something they can use.
3) Even if we can pull it off, it will make things harder for
developers. When 1.9 ships there will be two, maybe three Gecko
feature sets that developers have to be aware of --- 1.9, 1.8.1, maybe
1.8.0. If we add one feature in each 1.9.0.x release, we'll quickly
have a much larger collection of feature sets that developers will see
in the wild. "1.9.0.3 has downloadable fonts, 1.9.0.4 has video, now
which one had the selector API?" This problem will be worse if we fail
to shove the new features down the throats of distributors who don't
want them (see point 2).
There are a few features I'd be comfortable taking in 1.9.0.x --- very
low level stuff that does not reach upward to the complexity of Web
sites, is easy to test well, and is not directly exposed to
developers. Examples of this would be cairo performance, JS
performance, maybe SVG filter performance.
My preferred approach would be to roll up the features into a 1.9.1
release, which we do as soon as resources are freed by killing off the
1.8.1 branch.
My meta-preference is that a dictator resolve this issue once and for
all soon so we can all plan. I'd rather do a 1.9.0.x feature-fest than
carry on wrestling with this question.
Rob
Mike Shaver
> 1) Regressions on the stable branch are poison. Yes, we'll have test
> automation on the branch we never had before. Yes, we're talking about
> isolated features. But they're not fully isolated; for example,
> downloadable fonts will have to integrate with font selection (three
> implementations of).
I don't want to argue examples here; is it your belief that there is
_no_ platform feature so safe that we
> New features create regression opportunities,
> like it or not, and anything which cautions people against applying
> minor updates is extremely bad for them and for us. So I strongly feel
> we should minimize regression risk.
I believe that we _increase_ regression and exposure risk by adding
> (By the same argument I think we
> should actually be more conservative about security fixes than we have
> been on the 1.8.1 branch, by not taking patches for some of the more
> obscure bugs.)
I haven't heard you make that argument anywhere else; am I just
missing the bugs you've commented in, or whatever thread you mentioned
it on? I don't want to add it to the scope of this thread, because I
expect it to be pretty controversial, but I would like to discuss it
for sure. [My specific feelings about this position elided to avoid
making it the subject of this thread.]
> 2) At least some of our consumers (e.g. Thunderbird, most non-Firefox
> XUL apps, maybe mobile, probably Linux distros) will want to take
> security and stability fixes but the argument for having them take new
> platform features at the same time is weak. We should offer them
> something they can use.
Do we poll these groups about what we take in 1.9.1, as well? If
Mobile doesn't want <video>, do we not take it?
I'm not starting from the assumption that those other groups would
want to impose the cost of a third branch on us, necessarily, and I'm
not presuming to know what "they can use". I'm fine with asking them,
but treating it as certain just helps fulfill that gloomy prophecy. I
don't know why Thunderbird or other XUL apps would object to new
platform features if we do them well. Some of them might actually
_want_ them, for the same reasons we do.
Right now, we some Linux distributors maintaining the 1.5.0.x branch,
because their application needs it but the bulk of
> 3) Even if we can pull it off, it will make things harder for
> developers. When 1.9 ships there will be two, maybe three Gecko
> feature sets that developers have to be aware of --- 1.9, 1.8.1, maybe
> 1.8.0. If we add one feature in each 1.9.0.x release, we'll quickly
> have a much larger collection of feature sets that developers will see
> in the wild. "1.9.0.3 has downloadable fonts, 1.9.0.4 has video, now
> which one had the selector API?"
Version checking is a sucker's game, and I don't think we should be
hidebound by it. We should be putting these in version-indistinct
tech preview builds ahead of ship, which will help the key early
sample code and library use be pushed towards object detection and
content fallback. (I agree that we shouldn't ship things to content
that aren't safely detectable, which might mean that we have to change
how we do our wholesale W3C IDL imports now, if we provide partial
support for a given DOM standard.)
> This problem will be worse if we fail
> to shove the new features down the throats of distributors who don't
> want them (see point 2).
Again, I'm not taking that for granted, and I don't think you should either.
> There are a few features I'd be comfortable taking in 1.9.0.x --- very
> low level stuff that does not reach upward to the complexity of Web
> sites, is easy to test well, and is not directly exposed to
> developers. Examples of this would be cairo performance, JS
> performance, maybe SVG filter performance.
It's harder to test the compatibility effects of a worthwhile JS
performance win than to test the compatibility effects of
querySelectorAll or <video>; SVG filter coverage is even worse, I bet.
> My meta-preference is that a dictator resolve this issue once and for
> all soon so we can all plan. I'd rather do a 1.9.0.x feature-fest than
> carry on wrestling with this question.
I appreciate your support, but nobody lets me be dictator that way these days.
Mike
Mike Shaver
> On Sat, Mar 8, 2008 at 4:22 AM, Robert O'Callahan <rocal...@gmail.com> wrote:
> > automation on the branch we never had before. Yes, we're talking about
> > isolated features. But they're not fully isolated; for example,
> > downloadable fonts will have to integrate with font selection (three
> > implementations of).
>
> _no_ platform feature so safe that we
Ahem.
Is it your belief that there is no platform feature so safe that we
could take it on the branch? Performance is a feature (just ask
Apple; it's the only feature of their browser they advertise!) -- why
would the arch-conservative downstream projects not reject a JS engine
perf win, if they would reject a more isolated capability that can
make web-hosted apps more compelling?
> > New features create regression opportunities,
> > like it or not, and anything which cautions people against applying
> > minor updates is extremely bad for them and for us. So I strongly feel
> > we should minimize regression risk.
>
> I believe that we _increase_ regression and exposure risk by adding
Ahem, encore.
I believe that we _increase_ regression and exposure risk by adding a
third branch, thereby dividing effort (esp. manual-stochastic test
coverage) and increasing the likelihood that a ported patch has some
error not caught by our test suite.
Mike
Robert Kaiser
> <video> in 1.9.0.x. Worker threads in 1.9.0.x. querySelector in
> 1.9.0.x. Content-exposed JSON in 1.9.0.x. Follow-on XS-XHR in
> 1.9.0.x. Compatible ES4 features that are spec-stable enough in
> 1.9.0.x. Scriptable plugin API features in 1.9.0.x. Cairo tracking
> for perf and rendering quality in 1.9.0.x. SRP in 1.9.0.x.
I just realized, I hope none of those need any string/L10n changes, as
we promise localizers a hard L10n freeze for the whole 1.9.0.x cycle.
Robert Kaiser
Mike Shaver
Sure, and if we need string changes then we'll figure out how to get
them. If you're afraid of being sued by having us come back and
saying "we need a couple of new strings for 1.9.0.5, you have 2
months", then we could make 1.9.0.4 the last 1.9.0.x and call the next
one 1.9.1; I don't think those semantics are all that interesting,
though localizer impact is certainly one of the impacts we need to
assess.
(I think most of those features are string-neutral, or can be made so
for some cost in usability of error or configuration cases.)
That diamond-hard string freeze has made it hard for us to improve
security and usability on the branch in the past, I'm a little
surprised that we'd have signed up for it again. Do we really need to
make absolutist deals to get people to translate the product, or are
localizers interested in taking good trade-offs to improve things as
we go, with sufficient lead-time and tooling support?
Mike
Robert Kaiser
> Robert Kaiser wrote:
>
>> 1) Most other apps are not even near to anything shippable on 1.9.
>
> What has this got do with the discussion? Should we not do moz2 because
> of it? Or are you saying we *should* do 1.9.1 because of it? What's the
> practical difference between the two, for these other apps?
Yes, I think we probably should do a 1.9.1 because of them. And the
practical difference is that all our developers need to relearn the
whole toolchain of development tools.
> Code written in C++ will need to have the same automatic tranformations
> applied to it that we apply to gecko itself, but the tools will be
> available to do the transformations.
Well, if those rewriting tools are easily available to us - and the
rules stuff needed for that rewriting, it surely helps.
>> 4) The toolchain for apps outside mozilla-central is completely
>> unresolved, there isn't nearly a solution for this yet.
>
> This is also nonsense. Pulling multiple codebases together and hooking
> them up to the mozilla build is a problem that was solved over a year
> ago and contributed back from the Songbird project. The fact that it's
> mercurial and not CVS is a minor implementation detail.
You're seeing only part of the picture here, but if that system work
with something like client.mk (whatever it's called), that's one good step.
Of course, it's completely unresolved where all the parts of our current
codebase (the SeaMonkey one, including, platform, suite-specifics,
editor, mailnews, chatzilla, inspector, venkman, etc.) are going to live
in this moz2 world.
> Have you tried it, or are you just trying to lay a smokescreen to
> prevent real work from getting done?
I don't want to prevent real work, but putting a week into exploring
tools we won't actively use for many months to come means losing a week
in developing a release that should at least be in RC stage right now,
when we are pre-Alpha with some major roadblocks still in our way to
alpha. Losing time due to testing experimental crazy stuff and
relearning architecture is not an option IMHO at the current point. Ask
us again in fall if we tried it, and the answer might be different.
> Schrep's original post about the moz2 cycle, as well as followups on
> this thread, should make it clear that the moz2 cycle will be driven by
> continuous stability (and good tests).
The tests part sounds good, but I'm not convinced of the stability (as
in "interface", i.e. whatever hooks we need in the platform) as long as
I don't see it , which means we need at least see it with the platform
people's focus on development of moz2 and us trying to stay on top of
that, so I don't expect to get any idea of that until fall or winter of
this year (given we even make my dream schedule of a SeaMonkey 2 in
summer or fall).
Robert Kaiser
Robert Kaiser
> That diamond-hard string freeze has made it hard for us to improve
> security and usability on the branch in the past, I'm a little
> surprised that we'd have signed up for it again. Do we really need to
> make absolutist deals to get people to translate the product, or are
> localizers interested in taking good trade-offs to improve things as
> we go, with sufficient lead-time and tooling support?
If we want 100% of the languages we have for 1.9.0.0 available also
right for the release of 1.9.0.10, then yes, we probably need that
"diamond hard" string freeze.
The only way around it would be a fallback system like L20n has it,
which might make moz2 if Axel can find the time to work on this project
again (and I really hope so, for all of us, even if it might mean
rewriting all UI that accesses strings).
Robert Kaiser
Mike Shaver
> Benjamin Smedberg wrote:
> > Robert Kaiser wrote:
> >
> >> 1) Most other apps are not even near to anything shippable on 1.9.
> >
> > What has this got do with the discussion? Should we not do moz2 because
> > of it? Or are you saying we *should* do 1.9.1 because of it? What's the
> > practical difference between the two, for these other apps?
>
> Yes, I think we probably should do a 1.9.1 because of them. And the
> practical difference is that all our developers need to relearn the
> whole toolchain of development tools.
I think "whole toolchain" a pretty major overstatement, bordering on
outright falsehood. They need to relearn the version control system,
which they can already start doing experimentally; others have been
learning to use mercurial even while working on the CVS trunk, and
contributing to process requirement discussions based on their
experiences.
Their compilers, debuggers, bug tracking system, review model, test
harnesses, etc. are all the same -- is "working with CVS" really a
dominant part of app-developers time? If so, I would have expected
them to be much more involved in future-VCS discussions, since they
have so much at stake.
But also, there is no reason that a 1.9.1 wouldn't be done on
mercurial: if it's mostly a feature-integration stream, it will be
almost ideally suited to the distributed tools we have with hg. So
you should decouple those issues, I think, and complain about
1.9.1-on-hg if we decide to do a 1.9.1.
Mike
Mike
Robert Kaiser
> Their compilers, debuggers, bug tracking system, review model, test
> harnesses, etc. are all the same -- is "working with CVS" really a
> dominant part of app-developers time? If so, I would have expected
> them to be much more involved in future-VCS discussions, since they
> have so much at stake.
What about bonsai? mxr? tinderbox? all those work flawlessly with hg?
Without them working, there's no chance of getting many of our people
converted to this new world.
> But also, there is no reason that a 1.9.1 wouldn't be done on
> mercurial: if it's mostly a feature-integration stream, it will be
> almost ideally suited to the distributed tools we have with hg. So
> you should decouple those issues, I think, and complain about
> 1.9.1-on-hg if we decide to do a 1.9.1.
OK, if you want to close out all of us non-Firefoxies from the
repository, that would be a good idea indeed.
Robert Kaiser
Mike Shaver
> If we want 100% of the languages we have for 1.9.0.0 available also
> right for the release of 1.9.0.10, then yes, we probably need that
> "diamond hard" string freeze.
If that were true, I don't know how we got _more_ languages in 1.9.0
than we had in 1.8.1.x, since there was no such freeze between them.
Are you really saying that there is no amount of lead time or tooling
assistance that makes it possible to add a new string to 1.9.0.10? If
we knew on release day for 1.9.0 that we wanted to do it, that would
be about _sixty_weeks_ until 1.9.0.10, according to the tightest
interpretation of our current maintenance release schedule. That's
much longer that we would expect to give localizers to catch up to a
1.9.1 release, I'm pretty sure.
> The only way around it would be a fallback system like L20n has it,
> which might make moz2 if Axel can find the time to work on this project
> again (and I really hope so, for all of us, even if it might mean
> rewriting all UI that accesses strings).
I'd be pretty surprised if someone couldn't do a fallback-to-English
system without the whole L20N shebang; it sounds like a SoC-scale
project to me, if not on the small side for that.
But you can do fallback-to-English on a spot basis in the code as
well, where string bundles don't have the right string present. We
did that in Remora a few times when we wanted to add a warning or some
such for developers; just omitted it or used English if the
localization wasn't present.
(Also, JS errors in the console have never been localized, though the
JS engine has supported it for a decade or more, so for diagnostic
messages -- the vast majority of the string cases for platform
features -- I think we have pretty compelling existence proofs that
just using English is acceptable, if certainly not ideal.)
Mike
Mike Shaver
> Mike Shaver wrote:
> > Their compilers, debuggers, bug tracking system, review model, test
> > harnesses, etc. are all the same -- is "working with CVS" really a
> > dominant part of app-developers time? If so, I would have expected
> > them to be much more involved in future-VCS discussions, since they
> > have so much at stake.
>
> What about bonsai? mxr? tinderbox? all those work flawlessly with hg?
> Without them working, there's no chance of getting many of our people
> converted to this new world.
Without them working there's no chance of anyone getting onto that new
world, though I do think we have mozilla-central tinderbox coverage
now. Do you really think that you're the only one who cares about
having tinderbox coverage of their work? Really? Really really?
MXR is VC-independent. Even a SeaMonkey developer (see below) could
figure out how to switch it to mercurial. The bonsai discussion is
going on elsewhere, though the different use cases break down
differently. You don't need the "show my how to back out these
changes" thing nearly as badly once you actually have changeset, as
one example, and mercurial provides a built-in changelog visible from
the web.
(And I dispute your implied premise that these things work flawlessly
now, or that such should be a gate for transition. We have
bonsai-mirror-lag, we have tinderbox timing out against CVS or
conflicting out from time to time, we have reliance on timestamps
rather than changeset identifiers (!) We have all of MXR's other
performance and usability tragedies.)
> > But also, there is no reason that a 1.9.1 wouldn't be done on
> > mercurial: if it's mostly a feature-integration stream, it will be
> > almost ideally suited to the distributed tools we have with hg. So
> > you should decouple those issues, I think, and complain about
> > 1.9.1-on-hg if we decide to do a 1.9.1.
>
> OK, if you want to close out all of us non-Firefoxies from the
> repository, that would be a good idea indeed.
What, because only people on the Firefox team can use mercurial?
Trust me, I've met a lot of Firefox developers, they don't have some
mythic inborn VC intelligence that nobody else can have.
What are the _actual_ barriers that people are hitting that are
different for SeaMonkey than for Firefox? We have had mozilla-central
for people to work on and experiment against for some time now, and
we're getting feedback from people who are using it in different ways.
I haven't heard anything from you that isn't just a variation on
"change! other projects move faster than mine! run away!", but I
continue to hope that you're not really representative of the project
you represent.
Mike
Robert Kaiser
> On Sat, Mar 8, 2008 at 9:33 AM, Robert Kaiser<ka...@kairo.at> wrote:
>> Mike Shaver wrote:
>> > Their compilers, debuggers, bug tracking system, review model, test
>> > harnesses, etc. are all the same -- is "working with CVS" really a
>> > dominant part of app-developers time? If so, I would have expected
>> > them to be much more involved in future-VCS discussions, since they
>> > have so much at stake.
>>
>> What about bonsai? mxr? tinderbox? all those work flawlessly with hg?
>> Without them working, there's no chance of getting many of our people
>> converted to this new world.
>
> Without them working there's no chance of anyone getting onto that new
> world, though I do think we have mozilla-central tinderbox coverage
> now. Do you really think that you're the only one who cares about
> having tinderbox coverage of their work? Really? Really really?
No, but I don't even see examples of how all those things do work, as
not even Firefox has them yet, so I don't have any actual base to even
think of how to solve it for SeaMonkey - if I am able to do that
anyways. According to what some people here think of me, I'm probably
not even able to launch a computer and post to a newsgroup, I guess.
>> OK, if you want to close out all of us non-Firefoxies from the
>> repository, that would be a good idea indeed.
>
> What, because only people on the Firefox team can use mercurial?
Exactly. Everything else is not present in current hg, and trust me,
before we get near a SeaMonkey 2, our very very small team has no free
cycles to set something up for ourselves.
> I haven't heard anything from you that isn't just a variation on
> "change! other projects move faster than mine! run away!", but I
> continue to hope that you're not really representative of the project
> you represent.
OK, maybe I should just back out of all my Mozilla work, then.
Robert Kaiser
Robert Kaiser
> On Sat, Mar 8, 2008 at 8:13 AM, Robert Kaiser<ka...@kairo.at> wrote:
>> If we want 100% of the languages we have for 1.9.0.0 available also
>> right for the release of 1.9.0.10, then yes, we probably need that
>> "diamond hard" string freeze.
>
> If that were true, I don't know how we got _more_ languages in 1.9.0
> than we had in 1.8.1.x, since there was no such freeze between them.
> Are you really saying that there is no amount of lead time or tooling
> assistance that makes it possible to add a new string to 1.9.0.10? If
> we knew on release day for 1.9.0 that we wanted to do it, that would
> be about _sixty_weeks_ until 1.9.0.10, according to the tightest
> interpretation of our current maintenance release schedule. That's
> much longer that we would expect to give localizers to catch up to a
> 1.9.1 release, I'm pretty sure.
Many localizers only start working on things when a major release is
due, and that always has posed some kind of problem in this regard.
"source L10n" has made things easier, so I might be too cautious there,
but be sure to include Axel in any decision that affects this as he has
an in-deep picture of the current FF/platform L10n story across locales.
>> The only way around it would be a fallback system like L20n has it,
>> which might make moz2 if Axel can find the time to work on this project
>> again (and I really hope so, for all of us, even if it might mean
>> rewriting all UI that accesses strings).
>
> I'd be pretty surprised if someone couldn't do a fallback-to-English
> system without the whole L20N shebang; it sounds like a SoC-scale
> project to me, if not on the small side for that.
It can be done, but that is only one part of the suckage that current
L10n infrastructure is and that L20n would solve.
> But you can do fallback-to-English on a spot basis in the code as
> well, where string bundles don't have the right string present. We
> did that in Remora a few times when we wanted to add a warning or some
> such for developers; just omitted it or used English if the
> localization wasn't present.
We also did that in 1.8.0 for some security thing, and I understand it
was some pain on the code side, but has served L10n well.
Unfortunately things are not that easy for strings in DTDs, but I hope
we need none.
> (Also, JS errors in the console have never been localized, though the
> JS engine has supported it for a decade or more, so for diagnostic
> messages -- the vast majority of the string cases for platform
> features -- I think we have pretty compelling existence proofs that
> just using English is acceptable, if certainly not ideal.)
Erm, I see lots of localized stuff in error console, IIRC, even inside
error messages, which is sometimes fun when pasting those to IRC or
newsgroups in English channels/groups ;-)
Robert Kaiser
Michael Lefevre
[snip]
> If
> we knew on release day for 1.9.0 that we wanted to do it, that would
> be about _sixty_weeks_ until 1.9.0.10, according to the tightest
> interpretation of our current maintenance release schedule. That's
> much longer that we would expect to give localizers to catch up to a
> 1.9.1 release, I'm pretty sure.
But isn't that just doing something similar to 1.9.1, but with more
confusing numbering?
I guess you wouldn't actually want to commit to having exactly nine
1.9.0.x releases, so the 60-week-notice message would have to say to
localisers "we are allowing some new strings for the 1.9.0.x release after
X date".
Applying the same thing to addons, if you introduce, say, a video tag into
say, 1.9.0.8, then there may be extensions that work with 1.9.0.8 but not
1.9.0.7, which will (I guess) confuse AMO and stuff? Especially if you
can't identify the version when the video tag first works until after it
is released (as the numbering of the first release with the video tag
could get shifted at short notice by a security release)
Seems to me that having different levels of frozenness for different
1.9.0.x releases will cause confusion. Maybe the whole thing needs to be
a bit less frozen, or maybe there could be a jump to 1.9.1.x releases and
an immediate dropping of support for 1.9.0.x as of that point?
--
Michael
Michael Lefevre
> mercurial: if it's mostly a feature-integration stream, it will be
> almost ideally suited to the distributed tools we have with hg. So
> you should decouple those issues, I think, and complain about
> 1.9.1-on-hg if we decide to do a 1.9.1.
Well, if they can be decoupled and won't hold things up, then why don't
you folks switch to those tools now, for 1.9.0.0 and Firefox 3 beta 5?
It seems obvious that the Seamonkey folks want to do a release based on
1.9, shortly after Firefox 3 is out. Are you seriously saying that it
will not be harder and take longer to do that if they have to switch to hg
in the process?
On the other hand, if the primary motivation for 1.9.1 is to get some
stuff done for Seamonkey and/or Thunderbird, then maybe it would be easier
for them just to have a branch for that where they can do whatever they
want, and pick up security fixes from 1.9.0.x, rather than trying to make
a 1.9.1 which does everything for everyone?
--
Michael
sayrer
>
> However, I believe that there is a large set of changes and features
> that are important for us to work on that don't require or impact Moz
> 2 at all; for example (from areas that I'm most familiar with),
> <video> support, improvements to SVG, downloadable fonts, CSS
> border-image, etc. So, I'd like to propose the following plan:
>
> <http://people.mozilla.com/~vladimir/misc/branch-moz2.svg>
I do not think this is the best time to set such a policy. Instead, I
suggest we get feedback on available new features as soon as possible,
without committing to any release for those features.
I wrote up a strawman for this some time ago (please don't get hung up
on the priorities, they're mostly illustrative):
<http://wiki.mozilla.org/Technology_Preview>
This will get a pretty stable release with bleeding edge stuff into
users' hands quickly. This idea requires really strict testing
requirements, and I think that's OK. It will also avoid a debate about
which feature goes on which branch, and prevent schedule chicken. I
think the best strategy for Gecko versioning will be obvious once we
get a few of these out there. I find it very difficult to argue in
advance, and I think most of the arguments in this thread are based on
theoretical concerns (that could be correct, of course).
- Rob
Benjamin Smedberg
> What about bonsai? mxr? tinderbox? all those work flawlessly with hg?
> Without them working, there's no chance of getting many of our people
> converted to this new world.
bonsai == hg.mozilla.org (hgweb)
MXR == mxr
tinderbox == tinderbox or buildbot
They all work. There are some minor flaws, but those have been noted (mainly
knowing about the history of changes as pushed to a particular branch) and
will be fixed.
--BDS
Benjamin Smedberg
>> Without them working there's no chance of anyone getting onto that new
>> world, though I do think we have mozilla-central tinderbox coverage
>> now. Do you really think that you're the only one who cares about
>> having tinderbox coverage of their work? Really? Really really?
>
> No, but I don't even see examples of how all those things do work, as
> not even Firefox has them yet, so I don't have any actual base to even
> think of how to solve it for SeaMonkey - if I am able to do that
What the hell are you talking about? We have buildbot, reporting to
tinderbox, with nightly builds right now. We even have scripts that pull
multiple repositories to do the build, mixing mozilla and tamarin mercurial
repositories with NSPR and NSS CVS repositories.
It's a working example; it's proof that it can be done. Now it's just a
matter of the SeaMonkey project finding time to do it.
> Exactly. Everything else is not present in current hg, and trust me,
> before we get near a SeaMonkey 2, our very very small team has no free
> cycles to set something up for ourselves.
SeaMonkey has been grandfathered into our build system, resulting in
unfortunately tight couplings. I've argued since the beginning of the 1.9
cycle that seamonkey (and thunderbird) are going to have to remove these
tight couplings to survive successfully as projects: in particular the
autocomplete binding stuff in xul.css, but also the general "build on top of
XULRunner/libxul" projects. I know that these projects are moving forward.
Until they are complete, seamonkey is in the unenviable position of being
stuck, coupled too tightly to our build system.
I do not think that SeaMonkey being understaffed should significantly
influence our decisions about how the Mozilla project and codebase moves
forward. If the project is so understaffed that it cannot even track Mozilla
development in 1.9, how will 1.9.1 become magically better?
--BDS
Robert Kaiser
From what you say, everything sounds fine for moz2. We'll see for real
in fall or next year, whenever SeaMonkey will come around to actually
look into it and whoever will be doing the work then. It's good that we
have it here in the archives so that whoever will care about SeaMonkey
then will find those notices. I can't guarantee I'm around then. But
actually, who can?
For now, I'll keep this in the back of my mind, push it away from active
memory and tend to our immediate business.
Robert Kaiser
Robert O'Callahan
> On Sat, Mar 8, 2008 at 4:22 AM, Robert O'Callahan <rocalla...@gmail.com> wrote:
> > (By the same argument I think we
> > should actually be more conservative about security fixes than we have
> > been on the 1.8.1 branch, by not taking patches for some of the more
> > obscure bugs.)
>
> I haven't heard you make that argument anywhere else; am I just
> missing the bugs you've commented in, or whatever thread you mentioned
> it on? I don't want to add it to the scope of this thread, because I
> expect it to be pretty controversial, but I would like to discuss it
> for sure. [My specific feelings about this position elided to avoid
> making it the subject of this thread.]
I haven't pushed the idea so I don't expect you to have heard it. But
it's been in my mind for a few weeks.
https://bugzilla.mozilla.org/show_bug.cgi?id=415447#c12
> > 2) At least some of our consumers (e.g. Thunderbird, most non-Firefox
> > XUL apps, maybe mobile, probably Linux distros) will want to take
> > security and stability fixes but the argument for having them take new
> > platform features at the same time is weak. We should offer them
> > something they can use.
>
> Do we poll these groups about what we take in 1.9.1, as well? If
> Mobile doesn't want <video>, do we not take it?
No, that would be intolerable in the long term.
> I'm not starting from the assumption that those other groups would
> want to impose the cost of a third branch on us, necessarily, and I'm
> not presuming to know what "they can use". I'm fine with asking them,
> but treating it as certain just helps fulfill that gloomy prophecy.
True. You and Blizzard should go ahead and ask them. If your report
sets my mind at ease, great.
> > 3) Even if we can pull it off, it will make things harder for
> > developers. When 1.9 ships there will be two, maybe three Gecko
> > feature sets that developers have to be aware of --- 1.9, 1.8.1, maybe
> > 1.8.0. If we add one feature in each 1.9.0.x release, we'll quickly
> > have a much larger collection of feature sets that developers will see
> > in the wild. "1.9.0.3 has downloadable fonts, 1.9.0.4 has video, now
> > which one had the selector API?"
>
> Version checking is a sucker's game, and I don't think we should be
> hidebound by it. We should be putting these in version-indistinct
> tech preview builds ahead of ship, which will help the key early
> sample code and library use be pushed towards object detection and
> content fallback. (I agree that we shouldn't ship things to content
> that aren't safely detectable, which might mean that we have to change
> how we do our wholesale W3C IDL imports now, if we provide partial
> support for a given DOM standard.)
I'm not encouraging code-level version sniffing. However you detect
them, a plethora of feature sets creates complexity for developers:
additional code paths exercised, additional fallback required, and
additional thought and testing.
> > There are a few features I'd be comfortable taking in 1.9.0.x --- very
> > low level stuff that does not reach upward to the complexity of Web
> > sites, is easy to test well, and is not directly exposed to
> > developers. Examples of this would be cairo performance, JS
> > performance, maybe SVG filter performance.
>
> It's harder to test the compatibility effects of a worthwhile JS
> performance win than to test the compatibility effects of
> querySelectorAll or <video>; SVG filter coverage is even worse, I bet.
Alright, take JS off the list. Since SVG filters are barely used,
regressing them is not so critical.
Rob
Robert O'Callahan
> Is it your belief that there is no platform feature so safe that we
> could take it on the branch? Performance is a feature (just ask
> Apple; it's the only feature of their browser they advertise!) -- why
> would the arch-conservative downstream projects not reject a JS engine
> perf win, if they would reject a more isolated capability that can
> make web-hosted apps more compelling?
This is a game of tradeoffs. The world will not end if we take
platform features on branches. Regression risk is one downside, and I
have listed a couple of others, and stated my opinion that these
downsides suggest a 1.9.1 release makes more sense.
> I believe that we _increase_ regression and exposure risk by adding a
> third branch, thereby dividing effort (esp. manual-stochastic test
> coverage) and increasing the likelihood that a ported patch has some
> error not caught by our test suite.
I explicitly stated in my first message that I'm in favour of holding
the number of branches constant at 2.
Rob
Boris Zbarsky
> <video> in 1.9.0.x. Worker threads in 1.9.0.x. querySelector in
> 1.9.0.x. Content-exposed JSON in 1.9.0.x. Follow-on XS-XHR in
I've been thinking about this some more. It seems like we want to satisfy the
following constraints to get features out to web developers and make sure they
don't start to think of us as holding back the web while staying sane and
keeping users happy:
* Features shipping in a Gecko build
* Web developers realize that they are there
* Users are actually using that Gecko
* Avoid users feeling like they're on an upgrade treadmill
* Avoid having more than one security branch we maintain
* Avoid improvements breaking sites.
Shipping features in 1.9.0.x seems to satisfy the 1,3,4,5, since last I heard
uptake on the security releases was good, and users seem to be happy enough with
them. It might satisfy 6, but sites might have to do more testing on a
continuous basis. I'm not sure how well it would satisfy 2 unless we change the
way PR happens a good bit. We would certainly get less PR-bang than shipping a
single release with multiple new web-developer goodies.
Shipping a 1.9.1, etc, with a quick (6-month or less, if it's to be useful, imo)
cycle would have issues with some combination of 3,4,5 depending on how we
handle the updates and how good user uptake is. It's clear what the web
developer win would be here, but why should users upgrade? We don't necessarily
want to force them because that would contribute to the treadmill perception.
We end up with two branches (1.9.0.x, 1.9.1.x) in this scenario.
There's also the question of what the Firefox version numbers look like here.
Perhaps something to do is to add web-facing features into Gecko 1.9.0.x, have
Firefox tracking that, then call one of the Firefox releases, say based on
1.9.0.5, Firefox 3.1 and market it to web developers a little. Or something
like that. There are issues here with the extension versioning, of course.
Maybe the problem of web developer awareness isn't as big as I think it is; I
think I end up with a pretty tilted view based on the articles and blogs I've
been seeing. But it seems like people are slowly developing the perception that
we seriously lag Safari and Opera in standards support, and that's not a healthy
thing. The worst part is that the perception can persist even if it's no longer
true if we never make it clear that it's no longer true....
Just trying to get this out of my head so I can actually sleep,
Boris
Axel Hecht
> On Friday 2008-03-07 09:32 -0500, Mike Shaver wrote:
>> <video> in 1.9.0.x. Worker threads in 1.9.0.x. querySelector in
>> 1.9.0.x. Content-exposed JSON in 1.9.0.x. Follow-on XS-XHR in
>> 1.9.0.x. Compatible ES4 features that are spec-stable enough in
>> 1.9.0.x. Scriptable plugin API features in 1.9.0.x. Cairo tracking
>> for perf and rendering quality in 1.9.0.x. SRP in 1.9.0.x.
>
> So it occurred to me with a full 40 minutes to spare before the
> localization freeze that if this is the plan, some of these features
> might need new strings. I'm landing one string for bug 75375 in a
> few minutes.
>
> If anyone else can think of the same issue for other potential
> 1.9.0.x features, well, you have 22 minutes left.
>
> -David
>
I'm too ill to check, but I do hope that this didn't yield a plethora of
random string changes landing unapproved, just because it "might be
needed at some point for a new feature on 1.9.0.x".
Axel
Mike Beltzner
from happening.
I tried - unsuccessfully - to stress that while we should definitely think
about these issues, nobody should stress themselves out too much thinking
that we're going to make final decisions without vetting plans at public
meetings and providing time for feedback. Also, I don't think we should get
all stop energy-ish around strings. If we need to mobilize out localizer
community around doing a string release, we can talk about the costs and
benefits of doing so. We certainly have the technology to distribute that
code to users on an active product branch, it's just a question of
investment.
Anyway, back to the conversation at hand, which has several interesting
offshoots and tangents that are illuminating (at least, to me)
cheers,
mike
(apologies for the top-post, this is written on my BlackBerry)
Axel
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
schrep
> On Mar 7, 9:43 am, Doug Turner <doug.tur...@gmail.com> wrote:
>> i am not expecting to be on a mobile-specific branch. Ideally, what
>> we are planning for this year doesn't require large changes on to
>> 1.9. If we are wrong, we would switch over to Moz2.
>>
> imho, Mobile needs to follow the Mozilla 2 release.
>
Then Moz2 needs to release this year - because 1.9, as is, is good to go
for Mobile. We can and will do a mobile release this year.
Shawn Wilsher
> Then Moz2 needs to release this year - because 1.9, as is, is good to go
> for Mobile. We can and will do a mobile release this year.
the mobile team seemed to indicate that they were unsure if 1.9 was
good or not yet.
Cheers,
Shawn Wilsher
Stuart Parmenter
Then ship 1.9 for mobile -- no need for 1.9.1 if it is "good to go."
stuart
Dan Mosedale
> I know, but Calendar is still still working mainly on the 1.8 Branch and
> will only switch to whatever Thunderbird is using once TB3 is out. Our
> developers will certainly have to play catchup with all the architectural
> changes that have happened in the 1.9 timeframe, so looking at Moz2 stuff
> is just too far away to be of any interest or significance to us.
The above statement would seem to be incompatible with the idea of
shipping Lightning with Thunderbird 3, which is a postulated (though not
nailed down) goal. I think there are still some discussions between
calendar & Tb folks to be had, though they probably don't need to clog
up this thread.
Dan
Dan Mosedale
>
> On the other hand, if the primary motivation for 1.9.1 is to get some
> stuff done for Seamonkey and/or Thunderbird, then maybe it would be easier
> for them just to have a branch for that where they can do whatever they
> want, and pick up security fixes from 1.9.0.x, rather than trying to make
> a 1.9.1 which does everything for everyone?
>
As others have pointed out, having branches that _everyone_ needs to pay
attention is a very high cost in terms of context-switching. If the way
to avoid that is not to do a 1.9.1, that sounds workable to me. I
suspect that in that case, Tb might stay on 1.9-trunk as long as is
reasonable, and cut a private branch when the risk/churn became
unbearable. At some level, Tb wants to converge on being Just Another
Embeddor of libxul/xulrunner.
Dan
fantasai
If it's adding new features and the user-facing release is called Firefox
3.1, why would we not change our Gecko branch number to 1.9.1 instead of
1.9.0.5?
I'm against adding features in an n.n.n.n+1 release. It's just silly: what
are we going to do next time we want to distinguish "minor Gecko feature
improvements" vs. "just security fixes", tack on *another* number? Draw
the branches however you want, name the Firefox release whatever the PR
guys tell you, but if it's including new features it should be a third-level
Gecko rev up imho, not a fourth-level one.
~fantasai
Neil
> Do we have a way of fixing small polish/regression bugs that we weren't able to get to 1.9 before the next major release?
I may have overlooked it but I thought I read the whole thread yet I
didn't see an answer to this question.
My rationale is this: we are still converting SeaMonkey from xpfe to
libxul. This has uncovered a number or Core or Toolkit bugs or missing
features. It may uncover more that are as yet undiscovered. How are we
expected to deal with them in post-1.9 land?
Obviously this could depend on the impact of the bug so here are some
example bug numbers: 143065 (exposed by the switch to toolkit-based
preference system) 330101 363725 370109 379339 390771 395496 398874
399571 401388 406445 and 418213.
--
Warning: May contain traces of nuts.
anaesthetica
I think there's a good argument to have a 1.9.1 release before Moz 2.
Because of the major changes involved in Moz 2, it's unclear how
quickly that can be pushed out the door. Nor is there a compelling
reason to rush Moz 2, since it's so important at a fundamental level
to Mozilla as a platform. Better to do that one right than to do it
on an artificial timeline.
There was a minor flap not too long ago concerning whether Gecko was
basically just a Firefox oriented project, or whether it was a project
that was geared toward the entire ecosystem of products that use it
(SeaMonkey, Thunderbird, Camino, Songbird, Flock and so on). It was
argued at that time that Gecko 1.9.0 should not be delayed in order to
include specific fixes for these other projects, and that releasing on
time for the Firefox 3.0 deadline was top priority. Fixes for those
other application specific problems would, in general, wait.
A Gecko 1.9.1 release would presumably be geared toward the specific
fixes needed by all the other players in the Mozilla environment that
don't have the same priority as the flagship Firefox. That's
understandable. But eliminating a 1.9.1 release in order to focus on
Moz 2, which will land (at best) in 12 months, pushes off specific
fixes for the rest of the ecosystem even further.
It will be difficult to maintain four branches of Gecko code in
parallel--to that there is no argument. However, for the health of
the Mozilla ecosystem and for Gecko as a viable platform, a 1.9.1
release would seem to have undeniable benefits. In addition, above
posters have pointed out a number of pressing feature fixes for
Firefox itself that could do with a quicker release, and are not
inherently tied to the big changes in Moz 2. This is a strong
argument for a 1.9.1 release, despite the additional overhead of
coordinating four Gecko branches at once.
Jonas Sicking
This is definitely a hard problem. Ideally patches can be developed that
are safe enough to land post-1.9. The alternative is to try to find
resources that can get them fixed before 1.9 ships, which is getting to
be very short on time at this point.
It does seem like we're going to have another release not to far after
1.9 so this might be a good enough solution for now.
In general though I'm not really sure what possible solutions there can
be. We have to ship a given release at some point. I doubt that we will
ever be able to wait for fixes for all important bugs from all gecko users.
Do you have any suggestions?
/ Jonas
Greg K Nicholson
> In general though I'm not really sure what possible solutions there can
> be. We have to ship a given release at some point. I doubt that we will
> ever be able to wait for fixes for all important bugs from all gecko users.
>
> Do you have any suggestions?
Would it be feasible to have a Gecko 1.9.1 / Firefox 3.1 release
*replace* 1.9.0 / 3.0 ?
So it would essentially be a glorified 1.9.0.x / 3.0.x release with a
few new features added (but as little as possible *changed*).
I'm thinking particularly of things like Mardak's
awesomebar-with-added-awesomeness, that didn't land in time for 3.0.
If there were a general agreement that there were still enough things
missing from 1.9.1, there could be subsequent 1.9.x / 3.x releases.
Neil
Which RCS would 1.9.x use?
Benjamin Smedberg
> Would it be feasible to have a Gecko 1.9.1 / Firefox 3.1 release
> *replace* 1.9.0 / 3.0 ?
>
> So it would essentially be a glorified 1.9.0.x / 3.0.x release with a
> few new features added (but as little as possible *changed*).
Then why wouldn't you just call it 1.9.0.x?
The key distinguishing factors between 1.9.0.x and 1.9.1.x are:
* do users get silent security updates of Firefox, or optional major update?
* do we break extensions?
If we can add features without changing APIs and with a reasonable hope of
not breaking the web, we should just do it on the 1.9.0.x line.
If we have to change APIs or break extensions, we're stuck in a situation of
supporting the stable line for 6 months after the 1.9.1 line comes out, for
security and stability updates.
--BDS
Jonas Sicking
> Greg K Nicholson wrote:
>
>> Would it be feasible to have a Gecko 1.9.1 / Firefox 3.1 release
>> *replace* 1.9.0 / 3.0 ?
>>
>> So it would essentially be a glorified 1.9.0.x / 3.0.x release with a
>> few new features added (but as little as possible *changed*).
>
> Then why wouldn't you just call it 1.9.0.x?
>
> The key distinguishing factors between 1.9.0.x and 1.9.1.x are:
>
> * do users get silent security updates of Firefox, or optional major
> update?
> * do we break extensions?
>
> If we can add features without changing APIs and with a reasonable hope
> of not breaking the web, we should just do it on the 1.9.0.x line.
I don't really agree with this. A few reasons against doing this has
been brought up in this NG (I think in this thread even). One is that
1.9.0.x releases generally don't require l18n changes, which a new
feature generally would require. Another is that any new feature has a
big risk of breaking extensions in some way. For web features we have
examples like getElementsByClassName where just introducing a new
function broke a number of pages. As for chrome changes I imagine
anything with an id can affect overlays.
Any sort of breakage risks people getting turned off to the idea of
automatically applying security updates. Something that is really
important that it doesn't happen as it's one of our major tools to keep
the web safe.
There's also a risk that distributors will be more prone to cherry
picking the patches going into dot-release if we start putting new
features there. Again, this is something that we really want to avoid.
/ Jonas