Thoughs on 1.9, 1.9.1, and 2

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Boris Zbarsky
Mike Shaver wrote:
> 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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on 1.9, 1.9.1, and 2

Dan Mosedale
Banned User
This post was updated on .
In reply to this post by Robert Kaiser
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on 1.9, 1.9.1, and 2

Mike Shaver
On Fri, Mar 7, 2008 at 4:13 PM, Dan Mosedale <[hidden email]> wrote:
>  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)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Benjamin Smedberg
In reply to this post by 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?

> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

L. David Baron
In reply to this post by Mike Shaver
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

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Robert O'Callahan-2
In reply to this post by Boris Zbarsky
Put me down as against adding features to the 1.9.0.x branch:

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Shaver
On Sat, Mar 8, 2008 at 4:22 AM, Robert O'Callahan <[hidden email]> wrote:
>  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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Shaver
On Sat, Mar 8, 2008 at 7:34 AM, Mike Shaver <[hidden email]> wrote:
> On Sat, Mar 8, 2008 at 4:22 AM, Robert O'Callahan <[hidden email]> wrote:
>  >  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

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Robert Kaiser
In reply to this post by Vladimir Vukicevic-3
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.

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Shaver
On Sat, Mar 8, 2008 at 7:56 AM, Robert Kaiser <[hidden email]> wrote:
> 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.
>
>  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.

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Robert Kaiser
In reply to this post by Benjamin Smedberg
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.

> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Robert Kaiser
In reply to this post by Robert Kaiser
Mike Shaver wrote:
> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Shaver
In reply to this post by Robert Kaiser
On Sat, Mar 8, 2008 at 8:10 AM, Robert Kaiser <[hidden email]> wrote:

> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Robert Kaiser
In reply to this post by Robert Kaiser
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.

> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Shaver
In reply to this post by Robert Kaiser
On Sat, Mar 8, 2008 at 8:13 AM, Robert Kaiser <[hidden email]> 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.

>  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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Shaver
In reply to this post by Robert Kaiser
On Sat, Mar 8, 2008 at 9:33 AM, Robert Kaiser <[hidden email]> 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?

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Robert Kaiser
In reply to this post by Robert Kaiser
Mike Shaver wrote:

> On Sat, Mar 8, 2008 at 9:33 AM, Robert Kaiser<[hidden email]>  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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Robert Kaiser
In reply to this post by Robert Kaiser
Mike Shaver wrote:

> On Sat, Mar 8, 2008 at 8:13 AM, Robert Kaiser<[hidden email]>  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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Michael Lefevre
In reply to this post by Robert Kaiser
On 2008-03-08, Mike Shaver <[hidden email]> wrote:
[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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Michael Lefevre
In reply to this post by Robert Kaiser
On 2008-03-08, Mike Shaver <[hidden email]> wrote:
[snip]
> 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.

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
123