Closed Bug 544237 (C192Branch) Opened 11 years ago Closed 11 years ago

Set-up comm-1.9.2 branch

Categories

(MailNews Core :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sgautherie, Assigned: standard8)

References

Details

The repository is not created yet (like bug 522460) :-(
But we already have issues to track!
Flags: in-testsuite-
Alias: C192Branch
Blocks: 540470, 540380
Blocks: 511884
Will need to be done eventually; so marking NEW. not an indication that this is "READY" though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 545343
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 :-(
I was under the impression that the Thunderbird team didn't want to branch until very near to releasing their 3.1 release.
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.
(Sorry for losing track of this thread, BTW).
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.
OK, thanks for the advance notice.  I will confess to liking the "firmly unsupporting" idea quite a bit.  :-)
(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" :-(
(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.
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.
Blocks: 546177
(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.
(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.
(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. :)
No longer blocks: 511884
No longer blocks: 536374
No longer blocks: 540470
Blocks: 552688
No longer blocks: 552688
Blocks: 553525
Blocks: 553993
Blocks: 557042
No longer blocks: 540380
Blocks: 554311
Blocks: 560007
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.
Assignee: nobody → bugzilla
Severity: major → normal
Depends on: 560807
Depends on: 560808
Depends on: 560809
Depends on: 561333
Depends on: 561334
Depends on: 561814
Blocks: 562709
comm-1.9.2 is now alive and functioning: http://ccgi.standard8.plus.com/blog/archives/366
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Blocks: 560772
No longer blocks: 562709
No longer blocks: 560772
You need to log in before you can comment on or make changes to this bug.