Closed Bug 482451 Opened 13 years ago Closed 13 years ago
Rename l10n builders for central and 1
.9 .1 to be product first
3.33 KB, patch
|Details | Diff | Splinter Review|
1.33 KB, patch
|Details | Diff | Splinter Review|
1.39 KB, patch
|Details | Diff | Splinter Review|
I'd propose to use "%(product_name)s %(major_version)s %(platform)s l10n" That should order well on tinderbox, and be somewhat discoverable what things are for. Using the l10n branch would be better still, but that'd end up with releases/l10n-mozilla-1.9.1, which is awful. That's why I just went for 1.9.1. KaiRo likes similarities to download paths on ftp, but I don't mind that much, we have download links on the build boxes anyway.
Re-assigning to Armen as discussed in the releng-l10n meeting yesterday.
Assignee: nobody → armenzg
Priority: -- → P3
I'm not a huge fan of this change, since it makes the l10n builders use a different naming scheme than the rest of our builders, which are all <platform> <branch> <buildtype> Also, we are using "mozilla-central" instead of "1.9.2" everywhere else. Is there a good reason to have the l10n builders be named differently?
Yes, localizers don't care a bit about OS X 10.5.4 and whatnot. Nor do they care about how we're calling our machines for decades. They care about what they're working on, and that's Firefox. Branch. Possibly platform. Honestly, I don't think that platform is the most important thing to tell our core developers either, but I don't really start that argument.
First, we have builds of different products all report on the same tinderbox waterfall, so we need to include the product, preferably as first part so that things get sorted by it. The branch/version needs to be included, as well as the platform. Actually, the "l10n" bit is possibly unneeded. Localizers call up their Mozilla-l10n-<locale> page and want to see what the state of their builds is, and to see that "oh, Firefox trunk (-central, whatever) has a problem on Windows" or "SeaMonkey 2.0 (or 1.9.1 branch) is broken on all platforms" and find out from the according logs that they have am invalid Windows installer string for the former and missing chatzilla strings for the latter.
Is it possible to have one name show up in the buildbot waterfall and a different name for tinderbox? Axel: are l0n developers looking directly at the tinderbox pages or do they use the dashboard primarily? Could the dashboard insulate them from naming inconsistencies? I don't want to push this back on you, just looking for options.
For the buildbot waterfall, the name doesn't matter that much, as the name shows up in the order that the builders are added. At least afaict. We could fake the column name in tinderbox, via the columnName argument, but it's not recommended, says the comment. I agree, it's just adding confusion, and things are getting worse as soon as we drop tinderbox. Same goes for faking the buildername in the dashboard. Note that I don't see me showing the buildername there in my mental sketches. But that's all sketchy.
This bug will be fixed with patch https://bugzilla.mozilla.org/attachment.cgi?id=369009&action=edit from bug 484462
The patch is being run in mozilla-staging2 on windows and mac platforms and the results are being posted to http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaStaging Before I create the patch for production I would like to see what you think of introducing the following change: [b.strip() for b in config.get(section, 'builders').split(",")] for line: http://hg.mozilla.org/build/buildbotcustom/file/tip/l10n.py#l455 This change would allow us to have in l10nbuilds.ini builders separated by commas instead of having the un-natural backslashes. Regardless if we add this change or not I have to test the repack-on-change scenario before it goes into production since we have renamed the builders in l10nbuilds.ini. Coop, do you still have commit access for "x-testing"? I have also found what it seems to me an existing exception (since it shows up with and without the patch) and that does not seem to have any adversary effect. Any ideas? Shall I file another bug for this exception? ############## 2009-05-13 07:38:35-0700 [HTTPPageGetter,client] Starting factory <HTTPClientFactory: http://hg.mozilla.org/mozilla-ce2009-05-13 07:38:34-0700 [-] notifying downstream schedulers of changes 2009-05-13 07:38:34-0700 [-] Unhandled error in Deferred: 2009-05-13 07:38:34-0700 [-] Unhandled Error Traceback (most recent call last): File "/tools/buildbot/lib/python2.5/site-packages/buildbot-0.7.10p1-py2.5.egg/buildbot/master.py", line 759, in <lambda> d.addCallback(lambda res: self.loadConfig_Schedulers(schedulers)) File "/tools/buildbot/lib/python2.5/site-packages/buildbot-0.7.10p1-py2.5.egg/buildbot/master.py", line 835, in loadConfig_Schedulers d.addCallback(updateDownstreams) File "/tools/twisted-8.0.1/lib/python2.5/site-packages/twisted/internet/defer.py", line 194, in addCallback callbackKeywords=kw) File "/tools/twisted-8.0.1/lib/python2.5/site-packages/twisted/internet/defer.py", line 185, in addCallbacks self._runCallbacks() --- <exception caught here> --- File "/tools/twisted-8.0.1/lib/python2.5/site-packages/twisted/internet/defer.py", line 323, in _runCallbacks self.result = callback(self.result, *args, **kw) File "/tools/buildbot/lib/python2.5/site-packages/buildbot-0.7.10p1-py2.5.egg/buildbot/master.py", line 834, in updateDownstreams s.checkUpstreamScheduler() File "/tools/buildbot/lib/python2.5/site-packages/buildbot-0.7.10p1-py2.5.egg/buildbot/scheduler.py", line 350, in checkUpstreamScheduler for s in self.parent.allSchedulers(): exceptions.AttributeError: 'NoneType' object has no attribute 'allSchedulers' 2009-05-13 07:38:34-0700 [HTTPPageGetter,client] onLoadConfig called #################
I am trying to give an hour in which the columns "Firefox $branch $platform l10n" showed up in the MozillaStaging but they do not show up anymore. I looked in http://tinderbox.mozilla.org/admintree.cgi?tree=MozillaStaging but I don't see it there either. I know I saw the columns there when I had the slaves running.
Attachment #377171 - Flags: review?(ccooper) → review+
Attachment #377171 - Flags: review?(l10n) → review+
Comment on attachment 377171 [details] [diff] [review] Renames l10n builders to be "Firefox $branch $platform l10n" changeset: 1150:049d98b18607
Attachment #377171 - Flags: checkedâ€‘in+ checked‑in+
I don't know how that line when through but we have to get rid of it. The renaming is working in staging-master and here is a link to the tinderbox page: http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaStaging&maxdate=1242750160&legend=0&norules=1 The names are showing as: Firefox mozilla-1.9.1 linux l10n Firefox mozilla-1.9.1 macosx l10n Firefox mozilla-1.9.1 win32 l10n The mozilla-central columns should show later. We need to commit something into x-testing to confirm that the repack on change still works.
Attachment #378362 - Flags: review?(ccooper)
Attachment #378362 - Flags: review?(ccooper) → review+
Comment on attachment 378362 [details] [diff] [review] line that should have been removed changeset: 1151:403a2b42c337
Attachment #378362 - Flags: checkedâ€‘in+ checked‑in+
Repack on change has worked for x-testing: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaStaging/1242753308.1242753361.17003.gz&fulltext=1
Comment on attachment 377171 [details] [diff] [review] Renames l10n builders to be "Firefox $branch $platform l10n" >+ l10nNightlyBuilders[builder]['l10n_builder'] = \ >+ '%s %s %s l10n' % ( >+ branch['product_name'].capitalize(), >+ name, >+ platform) As a note, for SeaMonkey, I'm doing this with using the relatively new branch['brand_name'] as that has both capital letters in it :)
This bug is missing the production patch but I think it is better to wait for bug 480081 to land since it renames the l10n builders in l10nbuilds.ini Good to know about brand_name. Regarding choosing brand_name (Minefield, Shiretoko) instead of capitalized firefox plus the branch name is Axel's call.
BTW I just noted that repack-on-change is broken until this patch goes in. This happens for mixing the work of this bug with the bug of the l10n updates. *sigh*
Attachment #387007 - Flags: review?(ccooper)
Raising the priority since repack-on-change is not working until this goes in
Priority: P2 → P1
Attachment #387007 - Flags: review?(ccooper) → review+
Comment on attachment 387007 [details] [diff] [review] rename l10n builders for production "Firefox $branch $platform l10n" http://hg.mozilla.org/build/buildbot-configs/rev/468190878048
Attachment #387007 - Flags: checkedâ€‘in+ checked‑in+
Comment on attachment 387007 [details] [diff] [review] rename l10n builders for production "Firefox $branch $platform l10n" I reconfig'ed the master for this today.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.