In bug 607831, I'm investigating options for changing the way Socorro works with symbol files. We'll probably wind up converting our symbol files to a binary format in the short-term, and maybe moving them into HBase in the longer-term. Either way, it would be helpful to have a post-upload command that the build slaves could run from uploadsymbols, so that converting incoming symbols would be a simple process, and if we need to do something more complex (like store in HBase), we'll have that flexibility later.
Comment on attachment 486606 [details] [diff] [review] Allow specifying a post-upload command for uploadsymbols I hate that this is still a shell script, but switching things to use upload.py is probably more work than it's worth at the moment.
Attachment #486606 - Flags: review?(catlee)
Comment on attachment 486606 [details] [diff] [review] Allow specifying a post-upload command for uploadsymbols This patch should be a no-op until we fix the bugs it's blocking. This is necessary for some Socorro work we want to do to make processing faster.
Attachment #486606 - Flags: approval2.0?
Pushed to m-c: http://hg.mozilla.org/mozilla-central/rev/ed88ab5f4dbf
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
Backed out, hg rebase made a mess of my changeset. Will re-land shortly.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Pushed to m-c again: http://hg.mozilla.org/mozilla-central/rev/39a979e26931
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
I filed a bug upstream with hg on the rebase fail, FWIW: http://mercurial.selenic.com/bts/issue2471
Ted, when you request branch approvals for this, don't forget to ask for 1.9.0.next so that we can get Camino 2.0.x builds using the new system. ;) I'll be happy to do the actual checking-in on 1.9.0 for you, though, since I still have a CVS tree (the patch doesn't apply cleanly, but it's a trivial merge, and presumably it would not hurt to update upload-symbols.sh entirely).
Do we actually still do approvals for 1.9.0.x? I thought that branch was effectively dead. (Who's managing the approvals?)
(In reply to comment #9) > Do we actually still do approvals for 1.9.0.x? Yes, with varying degrees of lag. > (Who's managing the approvals?) The same branch-drivers as 1.9.x. Typically when approval1.9.0.next gets asked for at the same time as approval1.9.1.n/1.9.2.n, it's granted with the others; otherwise, I have to poke and poke.
Comment on attachment 486606 [details] [diff] [review] Allow specifying a post-upload command for uploadsymbols Requesting branch approvals. I'd like to land this on active branches in order to facilitate the Socorro work, so that we can do the symbol conversion server-side. This also gives us more flexibility in case we need to change something about symbol uploading in the future, we can simply change the script server-side.
Comment on attachment 486606 [details] [diff] [review] Allow specifying a post-upload command for uploadsymbols Approved for 22.214.171.124 and 126.96.36.199, a=dveditz for release-drivers Does this really apply correctly to the 1.9.0 branch? Seems like there might have been changes since then. Approved for 188.8.131.52, a=dveditz for release-drivers if so.
Maybe not, but I'd expect it to be a trivial merge if it doesn't. This code hasn't had a lot of churn.
Yeah, it's trivial; I checked earlier and it's just context (m-c and 1.9.2 have two attempts to fix quoting/MOZ_PKG_PRETTYNAMES and two attempts to do collision hashing that 1.9.0 doesn't have, and 1.9.1 is also lacking all but the very first attempt to fix quoting/MOZ_PKG_PRETTYNAMES).
Depends on: 609401
Checking in Makefile.in; /cvsroot/mozilla/Makefile.in,v <-- Makefile.in new revision: 1.405; previous revision: 1.404 done Checking in toolkit/crashreporter/tools/upload_symbols.sh; /cvsroot/mozilla/toolkit/crashreporter/tools/upload_symbols.sh,v <-- upload_symbols.sh new revision: 1.11; previous revision: 1.10 done
Thanks for the branch landings, I was travelling and busy with other things.
You need to log in before you can comment on or make changes to this bug.