Closed Bug 470679 Opened 15 years ago Closed 14 years ago

Provide automatic updates for l10n nightly builds

Categories

(Mozilla Messaging Graveyard :: Release Engineering, defect, P1)

Product:
Mozilla Messaging Graveyard
Component:
Release Engineering
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: stef, Assigned: gozer)

References

Details

Attachments

(1 file)

[checked in] Tweak to the output of make -C mail/locales ident
605 bytes, patch
standard8
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.0.5) Gecko/2008122108 Firefox/3.0.5 Flock/2.0.3
Build Identifier: 

When one will install en-US nightly build, the day after, it will update to the latest one (at least it should); when one will install ab-CD nightly it won't update at all.

Please provide aus support for l10n nightly builds, just like for en-US ones, since we are generating mar update files anyway, to lower the testing barrier, make our qa community life much easier and help it grow.

Reproducible: Always
Blocks: 470669
Status: UNCONFIRMED → NEW
Component: General → Release Engineering
Ever confirmed: true
Product: Thunderbird → Mozilla Messaging
QA Contact: general → release
Version: unspecified → other
Priority: -- → P2
Depends on: 449828
This is being worked out on dependent bugs for Firefox scenario. This will go live in the following weeks. You can already start looking at the patches to see how to port it to Thunderbird.
Depends on: 511510
Gozer, this went live for Firefox several weeks ago. Any chance of enabling this now for Thunderbird l10n nightlies. This would really help localizers, who are now doing QA after the string freeze for TB3 went into effect.
I agree we should do this asap, but I think it needs to be second to getting our mac nightlies stable - I'm sure there are some localizers using Mac, and getting builds out for them is a hit-and-miss affair although we do generally succeed at some point during the day.
Now that we are using the CC*Nightly factories, this should be relatively easy to enable. The only issues I can see is the added load on the build infrastructure, and the added load to the partial update generator. So, turning this one might have unexpected adverse effects.

I am going to look into enabling this this week (at least in staging) and see how that goes.

I also agree with Mark's point, getting stable OS X nightlies is definitely a priority.
Assignee: nobody → gozer
Priority: P2 → P1
There is some work that has also been done in patch-packager.pl that you might want to update to in whatever VM (in our case prometheus-vm) you have for generating partials.
comparing with ssh://hg.mozilla.org/build/buildbot-configs
searching for changes
changeset:   1582:e0b63dcd874f
tag:         tip
user:        Philippe M. Chiasson <gozer@mozillamessaging.com>
date:        Tue Oct 06 11:46:22 2009 -0400
summary:     enable nightly l10n updates on comm-central trunk
Depends on: 521000
Turns out that at some point, build_id has been renamed buildid in buildbot automation. Our make ident target still outputs/sets build_id (unused until now) but the l10n repack/update code needs a buildid set. This simple little patch just names the produced build_id, buildid.
Attachment #405263 - Flags: review?(bugzilla)
Comment on attachment 405263 [details] [diff] [review]
[checked in] Tweak to the output of make -C mail/locales ident

Ok, though how come updates work on SM without this? Are they on an older version?
Attachment #405263 - Flags: review?(bugzilla) → review+
Comment on attachment 405263 [details] [diff] [review]
[checked in] Tweak to the output of make -C mail/locales ident

a=Standard8 as well
(In reply to comment #8)
> (From update of attachment 405263 [details] [diff] [review])
> Ok, though how come updates work on SM without this? Are they on an older
> version?

Does Seamonkey have l10n updates ? This is only an issue for l10n snippet generation, really. build_id is otherwise ignored.
Comment on attachment 405263 [details] [diff] [review]
[checked in] Tweak to the output of make -C mail/locales ident

changeset:   4092:603ab1222f78
tag:         tip
user:        Philippe M. Chiasson <gozer@mozillamessaging.com>
date:        Thu Oct 08 12:10:11 2009 -0400
summary:     Bug 470679 - l10n updates for TB. Tweak to the output of make -C mail/locales ident. r+a=Standard8
Attachment #405263 - Attachment description: Tweak to the output of make -C mail/locales ident → [checked in] Tweak to the output of make -C mail/locales ident
There now should updates from the 20091010* to 20091011* l10n builds, not verified yet, but they are partial and complete updates published on aus.mozillamessaging.com
central only, right?
It looks that way. Having automatic updates on the 1.9.1 boxen would also be great.
Not sure if everything we need on the code side is landed on 1.9.1. Actually, I'm rather sure it isn't, I recall holding back on patches until 1.9.2 made a successful l10n release run, which it may or may not have by now. I don't recall which patches those were, though. Armen, do you?
(In reply to comment #13)
> central only, right?

Yes, right now, comm-central was the branch this is being tested on. Once comm-central looks like it's working fine, I'll enable it for comm-1.9.1.

It's already a bit of a challenge for the update generation system, suddendly having to move from 6 updates a day to 150+, but it's managing just fine.

I'd like to get confirmation of a succesfull update from a non en-US build, haven't actually tried it myself yet.
(In reply to comment #16)
> I'd like to get confirmation of a succesfull update from a non en-US build,
> haven't actually tried it myself yet.

Can confirm: 20091010031633 -> 20091012031705

Mozilla/5.0 (Windows; U; Windows NT 6.0; sk; rv:1.9.3a1pre) Gecko/20091012 Shredder/3.1a1pre
can confirm too:
Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.3a1pre) Gecko/20091012 Minefield/3.7a1pre

->

Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.3a1pre) Gecko/20091013 Minefield/3.7a1pre
(In reply to comment #18)
> can confirm too:
> Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.3a1pre) Gecko/20091012
> Minefield/3.7a1pre

Pascal: that's a minefield version number and we're not talking about that here. We're talking about Thunderbird builds.
oops, sorry, I jumped the gun too fast while skimming through my bugmail! I'll try thunderbird updates later today :)
(In reply to comment #16)
> It's already a bit of a challenge for the update generation system, suddendly
> having to move from 6 updates a day to 150+, but it's managing just fine.
>
lol we are in the same boat. Hopefully Coop's work will soon have us generate the updates on the slaves to drop the wait time.

(In reply to comment #15)
> Not sure if everything we need on the code side is landed on 1.9.1. Actually,
> I'm rather sure it isn't, I recall holding back on patches until 1.9.2 made a
> successful l10n release run, which it may or may not have by now. I don't
> recall which patches those were, though. Armen, do you?
On bug 512300 I tested that we could reach the end of a fake 3.6 beta release to that we don't hit the problems that were hit in the 3.5.2 release (https://wiki.mozilla.org/Releases/Firefox_3.5.2/BuildNotes#Build.2FRepack).
The bad merge had happened in bug 489313.
Can confirm: 20091010031633 -> 20091013030705

Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.9.3a1pre) Gecko/20091013 Shredder/3.1a1pre
l10n updates enabled on comm-1.9.1 nightlies. Should start pushing the snippets tonight, updates available 24 hours after that.
(In reply to comment #23)
> l10n updates enabled on comm-1.9.1 nightlies. Should start pushing the snippets
> tonight, updates available 24 hours after that.

snippets seem to be available however no updates present.
I recall Nick and Wil doing magic dances to get AUS to deliver snippets or something.
Had do disabled those, as they seem to be the cause for 523093, plus, buildbotcustom needs fixing, as it infers the branch name (for the snippet) from the hg repo path, so in our case it's always comm-central, which is wrong. There is no manual override, so I'll cook up a patch.
changeset:   1657:41aa61208fc3
tag:         tip
user:        Philippe M. Chiasson <gozer@mozillamessaging.com>
date:        Fri Oct 23 11:25:41 2009 -0400
summary:     Bug 470679 - Re-renable l10n updates for the comm-1.9.1 branch.
I've just successfully updated a en-GB build from 15th October to 25th October on the Thunderbird 3.0pre branch (gecko 1.9.1).

I'll verify partials tomorrow, but this looks like it is working now.
Updates from 20091024* to 20091025* are now available (partial and complete) and verified on Linux.
(In reply to comment #29)
> Updates from 20091024* to 20091025* are now available (partial and complete)
> and verified on Linux.

Well, Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1.5pre) Gecko/20091023 Lightning/1.0pre Shredder/3.0pre can't detect the updates so, it seems that there is still something broken.
Mozilla/5.0 (Windows; U; Windows NT 6.0; sk; rv:1.9.1.5pre) Gecko/20091026 Shredder/3.0pre

Partial updates seem to work fine as well, I've just successfully updated from 20091025 to 20091026. Full update (20091022 to 20091025) worked for me yesterday as well.
(In reply to comment #28)
> I've just successfully updated a en-GB build from 15th October to 25th October
> on the Thunderbird 3.0pre branch (gecko 1.9.1).
> 
> I'll verify partials tomorrow, but this looks like it is working now.

I just got a partial update too:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1.5pre) Gecko/20091026 Lightning/1.0pre Shredder/3.0pre
(In reply to comment #30)
> (In reply to comment #29)
> > Updates from 20091024* to 20091025* are now available (partial and complete)
> > and verified on Linux.
> 
> Well, Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1.5pre) Gecko/20091023
> Lightning/1.0pre Shredder/3.0pre can't detect the updates so, it seems that
> there is still something broken.

I just tried a pl build from 20091024 on Linux and that successfully updated to 20091026 (I couldn't actually see the 20091023 build on ftp).
An update worked for me too (updated to Mozilla/5.0 (Windows; U; Windows NT 6.1; lt; rv:1.9.1.5pre) Gecko/20091026 Shredder/3.0pre).

Shouldn't gozer resolve this as fixed?
(In reply to comment #34)
> An update worked for me too (updated to Mozilla/5.0 (Windows; U; Windows NT
> 6.1; lt; rv:1.9.1.5pre) Gecko/20091026 Shredder/3.0pre).
> 
> Shouldn't gozer resolve this as fixed?

Yes, he most certainly should!
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
No longer blocks: 547518
You need to log in before you can comment on or make changes to this bug.