Closed Bug 689909 Opened 13 years ago Closed 13 years ago

no build status display for l10n repacks

Categories

(Release Engineering :: General, defect, P2)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Pike, Assigned: armenzg)

References

Details

Attachments

(1 file)

Seems that switching off tinderbox impacted l10n, the tinderbox pages are empty now, and I haven't seen any replacement come up yet.
Assignee: nobody → armenzg
Attachment #563053 - Flags: review?(coop)
Comment on attachment 563053 [details] [diff] [review]
re-enable tinderbox mail for L10n

I'm not coop, but this looks like it would fix it; my alternate would be a disable_l10n_tinderbox_mail flag, that we default to true here. But either way.
Attachment #563053 - Flags: review+
(In reply to Justin Wood (:Callek) from comment #2)
> I'm not coop, but this looks like it would fix it; my alternate would be a
> disable_l10n_tinderbox_mail flag, that we default to true here. But either
> way.

s/true/false/ :/
Attachment #563053 - Flags: review?(coop) → review+
(In reply to Axel Hecht [:Pike] from comment #0)
> I haven't seen any replacement come up yet.

Is there a bug on file for that replacement yet? 

I know everyone was pretty cavalier about turning off tinderbox and it's affect on l10n, but I'd like to know we have a plan for how we're going to cope. Please cc me so I can help drive that forward.
Comment on attachment 563053 [details] [diff] [review]
re-enable tinderbox mail for L10n

checked-in 55d23e7e2285

We will reconfig after lunch.
Attachment #563053 - Flags: checked-in+
(In reply to Axel Hecht [:Pike] from comment #5)
> Seems that switching off tinderbox impacted l10n, the tinderbox pages are
> empty now, and I haven't seen any replacement come up yet.

Axel: This is expected and something we talked about when we met in person at allhands earlier this month. One of the specific topics was whether turning off email updates to tinderbox server would impact l10n at all. iirc you believed that l10n dashboard was not using any tinderbox pages, so we agreed this was fine to turn off these emails to tinderbox server. 

If this is no longer accurate, please give details of exactly what portion of l10n infrastructure is broken by these blank tinderbox pages, and we can work together to find a solution that works for l10n. Meanwhile, we will revert yesterdays work.
John, I understood you asking about specifically just the Firefox trees, and specifically excluding the repack builds, tabling the question of tinderbox for those for later. If I got that wrong, sorry.

For now, we'll need to switch the emails for the l10n builds back on, which has happened as I see, thanks.

Punchlines for going forward, as yammer posts say that's cool:
Releng is doing builds to publish via ftp etc.
There's no connection between the what l10n drivers do infrastructure-wise and those builds.
The most important asset right now is that releng has everything they need to say if the builds you expect are on ftp, and if not, why.
Everything else is icing on the cake and beyond the status quo.

Here's the longer why I say that, might be good to describe the current status quo as far as l10n builds go from my perspective:

For the reports on the releng l10n builds, I can see a few possible target audiences, ordering by the background of the releng builds, as in, "why what where how" (caveat, that ordering has little science to it):
- releng itself
- release drivers
- localizers
- the next other guy on the street

I'd see myself in the release driver bucket. I fail to understand our builds with the amount of context I have these days, and I guess that holds true for other release drivers. (SeaMonkey excluded.) When I see something that I don't expect, I file a releng bug to get that figured out. I don't expect localizers or community members to get that far.

So, in terms of status quo, the primary target audience for the data around the l10n builds is actually releng itself.

So looking at a replacement for tinderbox, you'd want to revisit what you're doing to answer the questions I or other release drivers have about the builds, what you need, what you want to improve, spec that out and get resources to implement that without tinderbox.

If we'd be talking about expanding the reach of people that can digest data about the l10n builds and take action on it, the actual release drivers like Christian, Mark, Callek should be the next guys to talk to. I would probably be the worst guy to talk to, as I'll be on vacation when things break, so the tad more background I have on l10n builds is going to play against us when we need it the most.

To extend that reach even further to localizers, I'd think that Armen and Rail are in the best position to comment. They're mentoring localizers in the last third of technical skills, I guess. They can probably lay out the gap to bridge between what data we have and what the localizers would be able to act upon.

Recap: to switch off tinderbox, releng should make sure they have everything they need to confirm that the bots do what they think they should, and answer questions raised. Beyond that, I'm happy to comment with my personal opinion, but I'd like to refrain as much as possible from speaking on behalf of other people that we can talk to directly.
The issue is now fixed.

Here is my understanding:
a) For the nightlies' status & builds localizers can go here: 
http://l10n.mozilla.org/~axel/nightlies/
which indirectly takes them to tinderbox [1]

b) For the status of compare-locales for the last check-in they can go here:
https://l10n-stage-sj.mozilla.org/dashboard/ (independent from releng)
b.1) releng also produces repacks on change which logs and binaries are uploaded to ftp but there is no dashboard to reach them besides tinderbox mail

c) Releng produces all the info is in here:
http://build.mozilla.org/builds/builds-4hr.js.gz
which can be seen on the json blurb below [4].

This information can lead us to the log [2] and to the build [3].

Axel from my understanding when you filed this bug is because A broke for you, correct?

From the information on C would you be able to modify your nightlies dashboard and not depend on tinderbox?

Once we solve the initial problem A I believe we can take a similar approach for b.1 even though as a localizer I really only care about the info that is on the L10n dashboard (b).


[1] http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-af&legend=0&norules=1&mindate=1317644956&maxdate=1317645332
[2] http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora-l10n/mozilla-aurora-linux64-l10n-nightly-cs-build2440.txt.gz
[3] http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora-l10n/firefox-9.0a2.gl.linux-x86_64.tar.bz2
[4]
    {
      "builder_id": 43981, 
      "buildnumber": 2440,  
      "endtime": 1317644525, 
      "id": 6652656, 
      "master_id": 30, 
      "properties": {
        "appVersion": "9.0a2", 
        "basedir": "/builds/slave/m-aurora-lnx64-l10n-ntly", 
        "branch": "mozilla-aurora", 
        "builddir": "m-aurora-lnx64-l10n-ntly", 
        "buildername": "Firefox mozilla-aurora linux64 l10n nightly", 
        "buildid": "20111003042017", 
        "buildnumber": 2440,  
        "builduid": "198bfdf96fc741ceb6b155c556911ec5", 
        "completeMarFilename": "firefox-9.0a2.gl.linux-x86_64.complete.mar", 
        "completeMarHash": "c6b92c8d21de5f481805dfa6a085dcdc216516ee0b99fc50a4e81e5e4deb066cd5df97e553792d6d041039b73a6a5cfa7b69ca57e81aec9827f04cf72353c34f", 
        "completeMarSize": "19105382", 
        "completesnippetFilename": "build/mozilla-aurora/dist/update/complete.update.snippet", 
        "en_revision": "default", 
        "filepath": null,  
        "forced_clobber": false, 
        "fx_revision": "79eab065f0d0", 
        "inipath": "dist/l10n-stage/firefox/application.ini", 
        "l10n_revision": "bc823ea66b77",
        "locale": "gl",
        "master": "http://buildbot-master13.build.scl1.mozilla.com:8001/",
        "partialMarFilename": "firefox-9.0a2.gl.linux-x86_64.partial.20111002042019-20111003042017.mar",
        "partialMarHash": "44accdef5517f1e86a414352fbd72f5621945da5494efa9862af0ec8a1e870ec7d9230d05eb5ff4c08b7c983bcb1be2ab54eec4b8743ce8352d8689cd8da46fa",
        "partialMarSize": "1209554",
        "partialsnippetFilename": "build/mozilla-aurora/dist/update/partial.update.snippet",
        "completeMarHash": "c6b92c8d21de5f481805dfa6a085dcdc216516ee0b99fc50a4e81e5e4deb066cd5df97e553792d6d041039b73a6a5cfa7b69ca57e81aec9827f04cf72353c34f", 
        "completeMarSize": "19105382", 
        "completesnippetFilename": "build/mozilla-aurora/dist/update/complete.update.snippet", 
        "en_revision": "default", 
        "filepath": null,  
        "forced_clobber": false, 
        "fx_revision": "79eab065f0d0", 
        "inipath": "dist/l10n-stage/firefox/application.ini", 
        "l10n_revision": "bc823ea66b77",
        "locale": "gl",
        "master": "http://buildbot-master13.build.scl1.mozilla.com:8001/",
        "partialMarFilename": "firefox-9.0a2.gl.linux-x86_64.partial.20111002042019-20111003042017.mar",
        "partialMarHash": "44accdef5517f1e86a414352fbd72f5621945da5494efa9862af0ec8a1e870ec7d9230d05eb5ff4c08b7c983bcb1be2ab54eec4b8743ce8352d8689cd8da46fa",
        "partialMarSize": "1209554",
        "partialsnippetFilename": "build/mozilla-aurora/dist/update/partial.update.snippet",
        "periodic_clobber": false,
        "platform": "linux64",
        "previousMarFilename": "firefox-9.0a2.gl.linux-x86_64.complete.mar",
        "previous_buildid": "20111002042019",
        "previous_inipath": "previous/application.ini",
        "product": "firefox",
        "project": "",
        "purge_actual": "142.63GB",
        "purge_target": "3GB",
        "purged_clobber": false,
        "repository": "",
        "revision": null,
        "scheduler": "Firefox mozilla-aurora linux64 l10n nightly",
        "slavebuilddir": "m-aurora-lnx64-l10n-ntly",
        "slavename": "linux64-ix-slave04",
        "stage_platform": "linux64",
        "partialsnippetFilename": "build/mozilla-aurora/dist/update/partial.update.snippet",
        "periodic_clobber": false,
        "platform": "linux64",
        "previousMarFilename": "firefox-9.0a2.gl.linux-x86_64.complete.mar",
        "previous_buildid": "20111002042019",
        "previous_inipath": "previous/application.ini",
        "product": "firefox",
        "project": "",
        "purge_actual": "142.63GB",
        "purge_target": "3GB",
        "purged_clobber": false,
        "repository": "",
        "revision": null,
        "scheduler": "Firefox mozilla-aurora linux64 l10n nightly",
        "slavebuilddir": "m-aurora-lnx64-l10n-ntly",
        "slavename": "linux64-ix-slave04",
        "stage_platform": "linux64",
        "toolsdir": "/builds/slave/m-aurora-lnx64-l10n-ntly/tools",
        "tree": "fxaurora"
      },
      "reason": "This build was triggered by the successful completion of the en-US nightly.",
      "request_ids": [
        5804654
      ],
      "requesttime": 1317644322,
      "result": 0,
      "slave_id": 1243,
      "starttime": 1317644337
    },
Sorry, but I've got to clear this up as clear as possible:

Reporting on l10n builds is a task outside of the scope of the l10n team or the elmo project.

Background on the nightlies page:
- it was a proof-of-concept, with releng as target audience. After all, the failures there are largely infrastructure problems.
- it's not maintained
- it only covers some aspects of our l10n builds, in a rather fragile manner, as in
-- it doesn't cover dep builds
-- it doesn't cover respins
- parts of it already regressed since I started it, too, i.e., it doesn't bother about fennec
Priority: -- → P3
Priority: P3 → P2
Depends on: 698910
I filed bug 698910 to take care of working on an alternative to Tinderbox for L10n.

We won't be disabling tinderbox for L10n until we have a solution for it.

Any reason to keep this bug open? If yes, I can un-assign it and leave it as P5 until webdev help us through on the bug I filed.

Sounds good?
Nah, I think this is fixed by sending stuff back to tinderbox, and the rest is good to do in bug 698910 or dependent/blocking bugs of that.
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.

Attachment

General

Created:
Updated:
Size: