> Two key costs are:
> * we're forced to keep up with API changes as they happen, which
> requires some amount of time and attention, especially if there's churn
> * we have to deal with whatever instability happens
It seems like this is no different than the way things have been up
until today on the 1.9 trunk. So, it's not a change.
I'd also note that if TB desires to make any changes to shared Core
code, that would seem preferable to have happen on trunk instead of 1.9.0.*.
Perhaps the question really boils down to if TB 3 plans to release on
1.9.1 or Moz2.
> I'd also note that if TB desires to make any changes to shared Core
> code, that would seem preferable to have happen on trunk instead of
> Perhaps the question really boils down to if TB 3 plans to release on
> 1.9.1 or Moz2.
It sounds to me like you're asking "Which released version of Gecko do
we want to ship on?", correct?
If we wanted to ship against a released version of Gecko, I'm sure we
wouldn't want to wait for Moz2 completion, which would leave us the
options of 1.9.0.* or 1.9.1(.*).
However, given the recent stability of the trunk, I'm inclined to work
under the assumption that we'll just ship with a Gecko based from some
arbitrary spot on the trunk. Tb would branch as late as it felt was
reasonable in order to get a stable Gecko. So if things start to get
unstable on trunk, then we'd look for the last stable point we could
find, and cut a branch based there.
This does contain the risk that if something is half done on the Gecko
trunk (e.g. the way cycle-collector was on the 1.9 trunk for a while),
things could get somewhat ugly (i.e. we'd have to go way back to branch
and possibly backport some stuff to older APIs). My understanding,
however, is that the intent is to manage mozilla-central such that that
sort of thing doesn't happen: features are developed on their own
branches and then merged to trunk when done.* If that understanding is
incorrect, though, please someone correct me now rather than later!
I'm not sure we can decouple the decision for what code we'd like to
build on or stay with from the question where at least the main chunk of
the code lives in this case.
While I agree that going with 1.9.1 might sound good, I'd like to see
things like regular builds, L10n, pull-what's-needed-together scripts
running well and being well-tested before we move our main development
onto that architecture. Having the cvs-to-hg move of the platform code
in the game makes the question larger than just about code, it's also
about having a somewhat stable infrastructure to work with (and the VCS
isn't really the problem there). This will be sorted out within weeks
probably, it just makes things a bit harder to decide right now.
An additional problem is that the current target for 1.9.1 to go stable
seems to be somehwere in Q1 2009, which means that we probably can not
by any means release a stable release before that date if we switch over
to 1.9.1 right now.
I originally envisioned SeaMonkey to release a 2.0 in Summer 2008 -
while I'd nowdays be glad if we manage to have an alpha out by then, I
still somewhat hope that we can go stable in late 2008, which is
probably hard to do on Gecko 1.9.1 if it's not supposed to be stable by
1.9.1.x seems better because there might be important non-Fx related
fixes that would go into the platform (and in turn Thunderbird 3), and
which are riskier than going into a stable "branch" like 1.9.0.x.
>> Perhaps the question really boils down to if TB 3 plans to release on
>> 1.9.1 or Moz2.
> It sounds to me like you're asking "Which released version of Gecko do
> we want to ship on?", correct?
I would probably have phrased it as:
Given that there seems to be a desire to ship a 1.9.1 release on a tight
schedule (aka: limited scope of changes), does that match up with the
desired Thunderbird 3 schedule? I haven't been following TB3 planning,
but with a few assumptions and by applying the Goldilocks Planning
Principle: 1.9.0.* feels too cold, 2.0 feels too hot, leaving 1.9.1 just
I'm not saying we can entirely decouple the decisions, details further
on in the message...
> While I agree that going with 1.9.1 might sound good, I'd like to see
> things like regular builds, L10n, pull-what's-needed-together scripts
> running well and being well-tested before we move our main development
> onto that architecture. Having the cvs-to-hg move of the platform code
> in the game makes the question larger than just about code, it's also
> about having a somewhat stable infrastructure to work with (and the VCS
> isn't really the problem there). This will be sorted out within weeks
> probably, it just makes things a bit harder to decide right now.
_If_ you try and decide them at all once, you're exactly correct that
the problem is too hard. Trying to make the decisions in an ordered
way, however, is likely to allow us to work around this. So what I'm
suggesting is that we start by making a (tentative) decision from a
product front on trunk vs. branch. Then, we say "given that tentative
decision, where do we need to get our Gecko code from and how can we
manage that in a way that everyone can live with?" Then, "given that
decision, where does Thunderbird want its code to live?". Etc. It's
absolutely possible that we're run into a dead end where we say "this is
too hard/impossible" and need to backtrack. But I'm proposing we cross
that bridge when we get to it.
> An additional problem is that the current target for 1.9.1 to go stable
> seems to be somehwere in Q1 2009, which means that we probably can not
> by any means release a stable release before that date if we switch over
> to 1.9.1 right now.
The last date I saw mentioned about 1.9.1 involved a projected ship of
November 2008, so I'm curious if there are channels of information that
Even if 1.9.1 were to slip out to finishing in Q1 2009, I don't think it
really matters all that much:
a) my understanding is that the trunk is going to be managed in such a
way that will fairly stable. See my response to Justin elsewhere in
this thread for more about that.
b) we're currently far enough from shipping that we can tolerate
instability for a while yet. Once that changes, we can cut a branch
from where we're at. But again, see my other post. :-)
I think many of the core code "bumps in the road" could be better controlled by changes in the build process.
A parallel production tinderbox something like this might do the trick:
Thunderbird production tbox___Gecko1.9.1____________________Backout core changes______Nightlies____Alphas__
Core changes App changes
Thunderbird Tinderbox builds>_______ Gecko 1.9.1 ________\______App Bustage__\___Nightlies____Nightlies
Couldn't we pull the code, then backout temporarily, whats holding up production, then build the tinderbox.
I do remember a host of problems when trying to re-land from the "aviary branch" when that was tried.
Right, we also have a few accessibility fixes we need for Thunderbird 3,
but which are irrelevant to Firefox, like bug 427841
<https://bugzilla.mozilla.org/show_bug.cgi?id=427841>. So if we could
land those core changes without affecting Firefox 3.0.x releases that
would be very helpful.
I'm wondering how you'd handle security releases on a thunderbird-only
My general feeling is that 1.9.0 isn't quite suitable for the next
version of Thunderbird.
Two things I can think of straight away, the password manager migration
routines may need to be extended a bit more to cope with news passwords
(which we could probably get into 1.9.0), but also I believe the
autocomplete functionality needs extending to include features that xpfe
has but toolkit hasn't (FF doesn't use these, but SM & TB do) - I think
these would be harder to fit into 1.9.0.
I expect there will be other things we want to change in core as well
(Cookie handling may be one, but don't ask me about that yet as I'm
still investigating the unit test problems).
I tend to agree here. There's nothing to say we must ship a stable
release of 1.9.1, although for extension developers it would be desirable.
So maybe a possibility here would be to release off an early 1.9.1 but
maybe ask that core interfaces are "frozen" until the full 1.9.1
release. We could then use the released 1.9.1 as the security branch.
It would, of course, help if we were synced with the gecko releases,
however, this hasn't happened for many reasons, but now we perhaps
should be looking to get back onto tracking them, or at least closer to
It would help to know what the 1.9.1 "tight schedule" is, but obviously
we're waiting for a post on that.
It would also depend on the branching aspects, are 1.9.1 and 2.0 two
branches, or one trunk and 2.0 will start merging later? Again, that's
probably what we need this post to tell us.
> Two key costs
* We have to convert to Mercurial. People keep enthusing about it on IRC
but I just don't get it, such as the 1-1 store/working directory
mapping. I hope updating is quick, as apparently I'm also going to have
to fix merge conflicts interactively, as it doesn't remember which files
are in conflict for me.
Warning: May contain traces of nuts.
A good point; this would require fixes to be ported from the nearest
appropriate spot (presumably many wouldn't require any actual porting
work, but some would) and could add significant cost. I'd be interested
in hearing from dveditz here...
I'm having a really hard time understanding what your ASCII art is
trying to indicate. Can you take a shot at clarifying?
My understanding is that the interface changes in 1.9.1 are going to be
pretty limited anyway. Again, though, it'd be helpful to have some
platform folks go into a bit more detail here...
This is true, but this is one of the things that I'd like to attack
later in the decision chain, if possible.
I think we are basically going to follow the same strategy between 1.9
and 1.9.1 as we did between 1.8 and 1.9. I.e. we are free to change any
non-frozen interfaces, but not any frozen ones.
The changes are going to be more limited though simply because there is
a much smaller time between the the branch point and the release.
The average nightly tester's choices for extended non-functional periods are to back up to the last functional build,
or, try each nightly and test...nothing.
> I think we are basically going to follow the same strategy between 1.9
> and 1.9.1 as we did between 1.8 and 1.9. I.e. we are free to change
> non-frozen interfaces, but not any frozen ones.
The only interfaces I *know* are going to be changing are those in
imglib, if that makes a difference, Dan.
Well that would fit with adding a few more attributes/properties to
toolkit's autocomplete, and correcting any "broken"/not implemented
migration of MailNews items for password manager.
> Well that would fit with adding a few more attributes/properties to
> toolkit's autocomplete, and correcting any "broken"/not implemented
> migration of MailNews items for password manager.
I suspect that SeaMonkey would like to see support for
"wallet.crypto.autocompleteoverride". Looking at the implementation of
_isAutocompleteDisabled in nsLoginManager.js, it looks like just a SMOP.
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]"Listen, have you seen the dolphins yet?" -Geordi
* TagZilla 0.066.6
Not long agao, there was a lot of talk that implied this could/would
even be allowed for 1.9.0.x, FWIW.
Which is why this part of the thread was talking about the possibilities
on the 1.9.1 development line.
On the other hand, if we need some non-security fix type changes in
gecko, it could be less difficult to get them into the trunk than the
I don't worry so much about trunk changes breaking Thunderbird since it
sounds like the changes are going to be limited in scope.
I have no idea about the overhead of converting to Mercurial.
I don't think this should really by of any concern to you, but I thought
I post it anyway. Going with the Mercurial version would mean that at least
in the next months we won't be able to further support the OS/2 version.
- I'm not sure where I read it but I have in the back of my mind that
the code in the Hg repository requires GCC >= 4.2. If that is true,
that is a big problem, because the newest we have is 3.3.5. (Even on
trunk/1.9 we had to work around a few issues to be able to keep building
with 3.3.x.) I haven't heard of any efforts to port GCC 4.2 to OS/2, yet.
- Hg itself isn't working on OS/2 currently. Some folks are working on
that, though, so this should hopefully be fixed some time soon.
Well, there actually is a third one: we are at a state with 1.9/FF3 where
it sort of works but there are still many things to fix before I would
recommend FF3 to end users. So we'll be busy enough with that for a while.