Re: Thunderbird v.next: branch or trunk?

0 views
Skip to first unread message

Justin Dolske

unread,
May 14, 2008, 7:12:39 PM5/14/08
to
Dan Mosedale wrote:

> 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.

Justin

Dan Mosedale

unread,
May 14, 2008, 7:30:45 PM5/14/08
to
Justin Dolske wrote:
>
> 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.

Agreed.

> 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.*.

Agreed.

> 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!

Dan

Robert Kaiser

unread,
May 14, 2008, 7:38:11 PM5/14/08
to
Dan Mosedale wrote:
> Other folks' thoughts?

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
then...

Robert Kaiser

Gary Kwong

unread,
May 14, 2008, 7:41:59 PM5/14/08
to
Dan Mosedale wrote:
> 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(.*).

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.

-Gary

Justin Dolske

unread,
May 14, 2008, 7:58:09 PM5/14/08
to
Dan Mosedale wrote:

>> 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
about right?

Justin

Dan Mosedale

unread,
May 14, 2008, 8:10:07 PM5/14/08
to
Robert Kaiser wrote:
> Dan Mosedale wrote:
>> Other folks' thoughts?
>
> 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.

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
I'm missing.

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. :-)

Dan

JoeS

unread,
May 14, 2008, 9:57:48 PM5/14/08
to
Dan Mosedale wrote:
> Justin Dolske wrote:
>>
>> 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.
>
> Agreed.
>
>> 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.*.
>
> Agreed.
>

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.

--
JoeS

Marco Zehe

unread,
May 15, 2008, 1:16:15 AM5/15/08
to
Hi all,

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.

Marco

Axel Hecht

unread,
May 15, 2008, 2:46:08 AM5/15/08
to
Dan Mosedale wrote:
> [Note that Followups have been aimed mozilla.dev.planning]
>
> Gecko stable (1.9.0.*) is staying on CVS. Gecko trunk is moving to
> Mercurial (hg). Thunderbird needs to decide how it wants to live in
> this world.
>
> My belief is that there are a bunch of slightly entrained but mostly
> separable issues around this, including where Thunderbird code wants to
> live, how it wants to handle patches to its copy of Gecko, how to best
> work with the calendar & SeaMonkey codebases, etc. My feeling is that
> if we try and sort through these all at once, it's going to be a big
> snarl. So I'd like to start with the question that seems to me to be
> the high-order bit, as it has a bunch of implications for the other
> questions. Once that's settled, we can sort through the rest,
> backtracking if absolutely necessary. My feeling is that this high
> order bit is "Should Thunderbird v.next be based on the stable 1.9.0.*
> branch of Gecko or trunk?"
>
> This feels to me like a product question. In particular there are two
> particularly big advantages to staying with the Gecko trunk:
>
> * we get the latest fixes, features, and performance wins without having
> to port patches. This is especially worthwhile for the case of big
> stuff that can't land on branch (e.g. splitwindow was a past example of
> this sort of thing)
>
> * we don't have to take a big painful hit and update all of our code to
> new APIs at some point in the future when we decide the branch has grown
> too stale. The cost of doing that updating is amortized over time, and
> moreover, we're likely to be able to provide feedback on Gecko API
> changes near the time they happen and before they've become more set in
> stone.

>
> 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
>
> My feeling is that we should stick with the Gecko trunk as long as it's
> reasonably stable and then branch if/when we have to (e.g. if it ever
> gets too unstable). The trunk has been quite stable for the last year
> or so (due IMO in large part to significantly better test coverage, and
> more aggresive backouts of regressions). Furthermore, the policies are
> getting slightly stricter once the Gecko trunk reopens in
> mozilla-central: <http://developer.mozilla.org/en/docs/mozilla-central>.
> Although they are also sort of liberalizing along the axis of no longer
> requiring approval or blocking+.
>

I'm wondering how you'd handle security releases on a thunderbird-only
gecko branch.

Axel

Mark Banner

unread,
May 15, 2008, 4:37:40 AM5/15/08
to
Dan Mosedale wrote:
> My feeling is that this high order
> bit is "Should Thunderbird v.next be based on the stable 1.9.0.* branch
> of Gecko or trunk?"

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).

Standard8

Mark Banner

unread,
May 15, 2008, 4:44:12 AM5/15/08
to
Dan Mosedale wrote:
>> 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
> I'm missing.
>
> Even if 1.9.1 were to slip out to finishing in Q1 2009, I don't think it
> really matters all that much:

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
those releases.

Standard8

Mark Banner

unread,
May 15, 2008, 4:47:39 AM5/15/08
to
Justin Dolske wrote:
> 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
> about right?

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.

Standard8

Neil

unread,
May 15, 2008, 5:19:30 AM5/15/08
to
Dan Mosedale wrote:

> 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.

Dan Mosedale

unread,
May 15, 2008, 8:15:46 PM5/15/08
to
Axel Hecht wrote:
>
> I'm wondering how you'd handle security releases on a thunderbird-only
> gecko branch.

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...

Dan

Dan Mosedale

unread,
May 15, 2008, 8:24:47 PM5/15/08
to
JoeS wrote:
>
> I think many of the core code "bumps in the road" could be better
> controlled by changes in the build process.

I'm having a really hard time understanding what your ASCII art is
trying to indicate. Can you take a shot at clarifying?

Thanks,
Dan

Dan Mosedale

unread,
May 15, 2008, 8:27:47 PM5/15/08
to
Mark Banner wrote:
>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.

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...

Dan

Dan Mosedale

unread,
May 15, 2008, 8:28:53 PM5/15/08
to
Neil wrote:
> Dan Mosedale wrote:
>
>> 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.
>

This is true, but this is one of the things that I'd like to attack
later in the decision chain, if possible.

Dan

Jonas Sicking

unread,
May 15, 2008, 10:05:55 PM5/15/08
to

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.

/ Jonas

JoeS

unread,
May 16, 2008, 7:38:57 PM5/16/08
to
All I'm saying is that when large impediments for further development, and testing, occur due to known issues in
core code, things simply come to a standstill until the issue is resolved.
I'm suggesting that if there was a parallel tinderbox to the trunk nightlies which could be patched -the offending
code, then testing and checkins could continue until the issue was resolved.
Kind of a temporary fork around the problem.

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.

--
JoeS

Joe Drew

unread,
May 16, 2008, 10:41:16 PM5/16/08
to dev-pl...@lists.mozilla.org

On May 15, 2008, at 10:05 PM, Jonas Sicking wrote:

> 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 only interfaces I *know* are going to be changing are those in
imglib, if that makes a difference, Dan.

Joe

Mark Banner

unread,
May 17, 2008, 4:14:36 AM5/17/08
to
Jonas Sicking wrote:
> Dan Mosedale wrote:
>> Mark Banner wrote:
>>> 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.
>>
>> 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...
>
> 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.

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.

Standard8

Philip Chee

unread,
May 17, 2008, 5:58:07 AM5/17/08
to
On Sat, 17 May 2008 09:14:36 +0100, Mark Banner wrote:

> 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.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
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

Robert Kaiser

unread,
May 17, 2008, 7:47:20 AM5/17/08
to
Mark Banner wrote:
> 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.

Not long agao, there was a lot of talk that implied this could/would
even be allowed for 1.9.0.x, FWIW.

Robert Kaiser

JoeS

unread,
May 17, 2008, 11:28:21 PM5/17/08
to
Ha, so a simple idea becomes, well, very mercurial.

Mark Banner

unread,
May 18, 2008, 8:36:22 AM5/18/08
to

Which is why this part of the thread was talking about the possibilities
on the 1.9.1 development line.

Standard8

David Bienvenu

unread,
May 19, 2008, 6:39:49 PM5/19/08
to
Dan Mosedale wrote, On 5/15/2008 5:28 PM:

> Neil wrote:
>> * 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.
>>
>
> This is true, but this is one of the things that I'd like to attack
> later in the decision chain, if possible.
>
> Dan
It sounds like our big unknown is when 1.9.1 is going to ship - it can
be difficult to ship a product based on gecko before gecko ships, and a
lot easier to ship afterwards. I'd really want to have a better idea of
when that's going to be in relation to when we'd like to ship and have
them roughly in sync.

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
branch.

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.

- David

Peter Weilbacher

unread,
May 22, 2008, 4:31:44 PM5/22/08
to
On 15.05.08 00:32, Dan Mosedale wrote:
> Gecko stable (1.9.0.*) is staying on CVS. Gecko trunk is moving to
> Mercurial (hg). Thunderbird needs to decide how it wants to live in this
> world.
[...]
> Other folks' thoughts?

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.
Two reasons:

- 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.

Cheers,
Peter.

Reply all
Reply to author
Forward
0 new messages