544237 - (C192Branch) Set-up comm-1.9.2 branch

Status: RESOLVED FIXED

(MailNews Core :: Build Config, defect)

Description

[Serge Gautherie (:sgautherie)]

The repository is not created yet (like bug 522460) :-(
But we already have issues to track!

Comment 1

[Justin Wood (:Callek)]

Will need to be done eventually; so marking NEW. not an indication that this is "READY" though.

Comment 2

[Serge Gautherie (:sgautherie)]

Dan, could you please proceed with setting up a comm-1.9.2 repository, so this bug could then be resolved too?

This is blocking work on various changesets listed at
http://dev.seamonkey.at/?d=x&i=mozilla&m=c
File Changes and Ports
and other blocked bugs!

It also forces to think and add useless "ifdef 192" in many patches in the meantime ... which we'll need to remove after branching:
2-3 times the needed work and reviews :-(

Comment 3

[Robert Kaiser]

I was under the impression that the Thunderbird team didn't want to branch until very near to releasing their 3.1 release.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

I had intended to ping back about this discussion, but that got lost under other work I was doing.  A bunch of Thunderbird folks talked this over a few weeks back, and we came to the conclusion that our branching strategy for 1.9.1 embodied the right economics: it doesn't make sense to branch until the cost of not branching is higher than the cost of branching.  Given that the cost of double checkins for every patch (triple for bugs that effect 3.0.x) feels significantly higher than the cost of ifdefs or time delay for a much smaller subset of patches, we don't think we're there yet, and probably won't be for a while.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

(Sorry for losing track of this thread, BTW).

Comment 6

[Robert Kaiser]

We have a number of bugs piling up that probably require branching, see dependencies. That's OK as the dependency will remind us why they haven't landed yet.
In any case, bug 536374 is a SeaMonkey 2.1a1 blocker if we ship that one from 1.9.3, which is likely, so we might need to have some kind of branching for shipping that release. That isn't meant as pressure on Thunderbird folks or anything, just as a note. It might not even need actual branching, but firmly unsupporting 1.9.2-based builds for SeaMonkey might be just enough.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

OK, thanks for the advance notice.  I will confess to liking the "firmly unsupporting" idea quite a bit.  :-)

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to comment #4)
> we came to the conclusion that our branching strategy for 1.9.1
> embodied the right economics

The current situation is different than what it was:
m-1.9.1 was the only branch, with m-c as trunk, and we were far far behind,
m-1.9.2 is now a _branch_ too, with m-c as trunk, and we're not so far behind,
branching asap (now) would give us a chance to become near behind only.

(In reply to comment #6)

Fwiw,

> We have a number of bugs piling up that probably require branching, see
> dependencies. That's OK as the dependency will remind us why they haven't
> landed yet.

Not "OK" by me, as some of these bugs exist only because of non-branching: like bug 545343.
And they are (many) more I have begun to check (from the list), which are in the same case, but I'm just loath of filing more 'Future' bugs.

> In any case, bug 536374 is a SeaMonkey 2.1a1 blocker if we ship that one from
> 1.9.3

This is just one (SeaMonkey) case.
On the c-c "configure" list (and elsewhere), new bugs add themselves to the blocked list.
c-1.9.1 had bugs from m-1.9.1 which were not ported in time; I'm trying to cope with the m-1.9.2 backlog (stupid me!); meanwhile, I see m-1.9.3 changesets forced to backlog too instead of being ported "synchronously" :-(

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #8)
> (In reply to comment #4)
> > we came to the conclusion that our branching strategy for 1.9.1
> > embodied the right economics
> 
> The current situation is different than what it was:
> m-1.9.1 was the only branch, with m-c as trunk, and we were far far behind,
> m-1.9.2 is now a _branch_ too, with m-c as trunk, and we're not so far behind,
> branching asap (now) would give us a chance to become near behind only.

As far as I can tell, all of the statements you make above are true.  However, I don't think any of them change the fact that "it doesn't make sense to branch until the cost of not branching is higher than the cost of branching" is fundamentally the right way to think about this.

So I guess I don't really understand what you're trying to point out.

> (In reply to comment #6)
> 
> Fwiw,
> 
> > We have a number of bugs piling up that probably require branching, see
> > dependencies. That's OK as the dependency will remind us why they haven't
> > landed yet.
> 
> Not "OK" by me, as some of these bugs exist only because of non-branching: like
> bug 545343.
> And they are (many) more I have begun to check (from the list), which are in
> the same case, but I'm just loath of filing more 'Future' bugs.

You're right that there are costs on all sides here.  There is no path we can choose which doesn't involve significant costs.  The best we can do is hope to minimize those costs.

Comment 10

[Robert Kaiser]

As a note, from bug 534221 comment #31:
"1.9.3 doesn't use chromedir so we don't need the global.dtd. If we don't care
about 1.9.2 I can remove these."

This affects any place in any UI bit anywhere on comm-central where the chromedir attribute is being used in XUL to support RTL. I'm not sure how good we are at RTL support in any of our apps, but this is something to look at for sure. Not saying we need to branch immediately to allow it, just to watch out for it and keep it in mind. Maybe we should file a dependent bug to switch over to the new ways for sure once we are branched.

Comment 11

[Serge Gautherie (:sgautherie)]

(In reply to comment #9)
> I don't really understand what you're trying to point out.

My key points are: c-1.9.1 has released, m-1.9.2 has released, c-c is used to work with (both) m-1.9.2 and/or m-c.
I tried to point out that I thought the different problem with current c-c should (now) lead to a different solution than the one which was (correctly) chosen for c-1.9.1.
That said, it's just my opinion and I wanted your comment which I now have :-|

(In reply to comment #10)
> Maybe we should file a dependent bug to switch over
> to the new ways for sure once we are branched.

I'd suggest that indeed, as this is wanted but won't happen in this very bug.

Comment 12

[Mark Banner (:standard8)]

(In reply to comment #10)
> As a note, from bug 534221 comment #31:
> "1.9.3 doesn't use chromedir so we don't need the global.dtd. If we don't care
> about 1.9.2 I can remove these."
> 
> This affects any place in any UI bit anywhere on comm-central where the
> chromedir attribute is being used in XUL to support RTL. I'm not sure how good
> we are at RTL support in any of our apps, but this is something to look at for
> sure. Not saying we need to branch immediately to allow it, just to watch out
> for it and keep it in mind. Maybe we should file a dependent bug to switch over
> to the new ways for sure once we are branched.

The statement bug 534221 is wrong. AFAICT bug 478416 did the switch away from chromedir and that was implemented for 1.9.2 (as hinted by https://developer.mozilla.org/en/Making_Sure_Your_Theme_Works_with_RTL_Locales#Gecko_1.9.2_and_later). TB has already done this, so SM can do this now without issue.

Comment 13

[Robert Kaiser]

(In reply to comment #12)
> The statement bug 534221 is wrong. AFAICT bug 478416 did the switch away from
> chromedir and that was implemented for 1.9.2

Ah, OK, I just knew it was done post-1.9.1 but wasn't sure if it was in 1.9.2 or not, was following that other statement - wrongly, as it seems.
Good, as it makes us diverge less on that stuff. And SeaMonkey doesn't have to do that much as we've not done a lot of chromedir previously, we suck at RTL right now and don't have anyone doing work for it. But that belongs in a different bug, as you said.

For branching, this topic seems to be no concern after all. :)

Comment 14

[Mark Banner (:standard8)]

Current plan is to do this the backend of this week / start of next week, so taking bug. All the work will be done in dependent bugs which I'll start filing in a day or so.

Comment 15

[Mark Banner (:standard8)]

comm-1.9.2 is now alive and functioning: http://ccgi.standard8.plus.com/blog/archives/366