Mark Banner (:standard8) Assignee
	Description • 15 years ago

This is the tracking bug for setting up the comm-1.9.1 branch.

I'll be working on this gradually over the next few days and filing various dependent bugs as necessary. The target is to switch over to the branch on the 22nd October.

	Mark Banner (:standard8) Assignee
	Comment 1 • 15 years ago

I've just done some testing to confirm what I've been told and we can set up a new repository and run it "in sync" with comm-central for a few days until we're actually ready to do the branch.

The basic mechanism here will be: people push to comm-central, then once a day (ish) I'll push the changes to the new repository. As long as the new repository doesn't have separate pushes we'll be fine. I'll blog/post more about this once I've filed the bug to create the repository.

I'm hoping that in setting this up early gozer can do test buildbot changes on staging that we can then merge to production. I know SeaMonkey hasn't got staging, but hopefully SeaMonkey can pick up on the changes that gozer does.

I'm proposing we use the following repository:

http://hg.mozilla.org/releases/comm-1.9.1/

I think that's pretty much what everyone is expecting anyway and reflects the mozilla-* version.

	Robert Kaiser
	Comment 2 • 15 years ago

(In reply to comment #1)
> The basic mechanism here will be: people push to comm-central, then once a day
> (ish) I'll push the changes to the new repository. As long as the new
> repository doesn't have separate pushes we'll be fine. I'll blog/post more
> about this once I've filed the bug to create the repository.

Sounds good. The changes on the buildbot side for the new repo should be pretty easy, as we already have the branches set up in the config, we just need to adjust the repo names. I think the hardest part overall is the client.py thing.

> I'm proposing we use the following repository:
> 
> http://hg.mozilla.org/releases/comm-1.9.1/

Exactly what I thought it would be all along :)

	Philippe M. Chiasson (:gozer)
	Comment 3 • 15 years ago

(In reply to comment #2)
> (In reply to comment #1)
> > The basic mechanism here will be: people push to comm-central, then once a day
> > (ish) I'll push the changes to the new repository. As long as the new
> > repository doesn't have separate pushes we'll be fine. I'll blog/post more
> > about this once I've filed the bug to create the repository.
> 
> Sounds good. The changes on the buildbot side for the new repo should be pretty
> easy, as we already have the branches set up in the config, we just need to
> adjust the repo names. I think the hardest part overall is the client.py thing.

I agree. Plus on my side of things, conceptually, the 2 'branches' are already branches as far as buildbot is concerned. There are actually a few hacks in there to keep buildbot happy about this, so once we are proprely branched, I'll be able to get rid of some of that ugliness, so that's great.

client.py will just need to pick different defaults depending on which branch it's on. Just made me think of something, why not stick a top-level client.cfg or some such file where client.py gets it's defaults from (branch, revisions, etc) instead of in client.py itself. That way, should be easy to keep client.py 100% identical across branches, and isolate the changes to that single config file. Thoughts ?

	Axel Hecht [:Pike]
	Comment 4 • 15 years ago

Here are the things that I see coming up for l10n:

Get new trees for comm-central against ... ? mozilla-central and l10n-central again?

Figure out a list of locales that want to localize comm-central. We have a similar discussion going for Firefox right now in .l10n, and how that impacts how we branch 1.9.3. Did you guys figure out yet what you want to do once 1.9.3 branches?

	Mark Banner (:standard8) Assignee
	Comment 5 • 15 years ago

(In reply to comment #4)
> Get new trees for comm-central against ... ? mozilla-central and l10n-central
> again?

We already have infrastructure that builds comm-central with mozilla-central and the l10n central repositories - however I believe only the l10n dashboard isn't set up for it.

At the moment my main objectives are:

- Branch comm-central into comm-1.9.1 and get the defaults set up right.
- Get comm-central back to building with mozilla-central (by default) and appropriate repositories.

Whether or not we then do something to pick up 1.9.2 I don't know - we haven't had in depth discussions on that yet, and it may differ for the different apps in comm-central.

> Figure out a list of locales that want to localize comm-central. We have a
> similar discussion going for Firefox right now in .l10n, and how that impacts
> how we branch 1.9.3. Did you guys figure out yet what you want to do once 1.9.3
> branches?

As I implied above, we haven't really figured out much beyond Thunderbird 3.

I don't quite see how what localizes against comm-central affects branching for 1.9.3, given our locales have the strings in the same repos as Firefox aren't we constrained by what Firefox does there?

	Axel Hecht [:Pike]
	Comment 6 • 15 years ago

We expect to branch the majority of the 1.9.3 l10n repos from 1.9.2 and not from central, and restrict central to only those locales actively working on it. Branching 1.9.2 from central was painful and lossy. More in http://groups.google.com/group/mozilla.dev.l10n/browse_frm/thread/dd79bc10a37faf89#. Restricting central to a smaller set of locales cuts down on system load for one, but also makes it explicit who'd be branching from where for .3.

Whatever comm-central does is likely going to be tough for l10n, as the landings they have for that on 1.9.1 need to be manually ported, most likely. Or trickily merged, neither is gonna come easy.

Regarding the l10n dashboard, "only" isn't exactly the way I'd put it. In our (including KaiRo here at least) experience, the l10n community looks at the dashboard alone, and grabs builds from ftp. And completely ignores anything tinderbox.

	Robert Kaiser
	Comment 7 • 15 years ago

(In reply to comment #6)
> Whatever comm-central does is likely going to be tough for l10n, as the
> landings they have for that on 1.9.1 need to be manually ported, most likely.
> Or trickily merged, neither is gonna come easy.

Right. And with that being the case with any decision we make, I'm inclined to say that's good because it doesn't force us either way. Still, it will not be too much fun to get that up the right way, and I expect that it'll take a couple of weeks until localizers are up to speed again - that's why I'd like to do it as rarely as possible (or have us branching nearer in sync with the main Mozilla repo in the future).

In any case, it will be those for the moment:
comm-1.9.1 + mozilla-1.9.1
comm-central + mozilla-central

Any further action will be determined once SeaMonkey and Thunderbird both have our major releases out the door, so I won't expect a decision before December.

	Mark Banner (:standard8) Assignee
	Comment 8 • 15 years ago

Tree is closed.

COMM_1_9_1_BASE tag applied to comm-central and comm-1.9.1:

http://hg.mozilla.org/comm-central/rev/ba87fbcd9142
http://hg.mozilla.org/releases/comm-1.9.1/rev/ba87fbcd9142

We still need to do the client.py change on comm-central, but that will be ready soon.

	Mark Banner (:standard8) Assignee
	Comment 9 • 15 years ago

I've just raised bug 523820 for removing the MOZILLA_1_9_1_BRANCH ifdefs from comm-central.

For comm-1.9.1 I'm going to suggest we leave them alone, unless a) there are specific build advantages for not having them (e.g. not preprocessing files) or b) unnecessary complexities that we feel we want to simplify.

	Mark Banner (:standard8) Assignee
	Comment 10 • 15 years ago

Status update:

- The trees have now been formally branched and comm-central will now pull from mozilla-central, and comm-1.9.1 from mozilla-1.9.1.

- The trees are staying CLOSED until the morning at the earliest. SeaMonkey is having some issues with their Windows builders, and the Thunderbird buildbot is suspected of having some issues (TBC) plus the builders need a bit more time to cycle through to green.

	Robert Kaiser
	Comment 11 • 15 years ago

(In reply to comment #10)
> - The trees are staying CLOSED until the morning at the earliest. SeaMonkey is
> having some issues with their Windows builders, and the Thunderbird buildbot is
> suspected of having some issues (TBC) plus the builders need a bit more time to
> cycle through to green.

As a note, the issues with SeaMonkey Windows builders are not due to branching itself, but due to me using the tree closing and needed login to clobber the 1.9.1 trees to also work on bug 520687 and install both a new MozillaBuild as well as the Win7 SDK on those machines. This unfortunately had some unexpected fallout, reopening the trees can be done despite that, it's machine config issues only.

	Mark Banner (:standard8) Assignee
	Comment 12 • 15 years ago

The only remaining issues are l10n dashboard (SM-only change still needed) and updating MoCo's tbpl. As these are effectively both minor, there's nothing more I need to drive so marking as fixed.