Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
483853002:
Revert of Revert of Make ninja display elapsed compile time by default. (Closed)
|
Created:
6 years, 4 months ago by jabdelmalek Modified:
6 years, 1 month ago CC:
chromium-reviews, kjellander-cc_chromium.org, cmp-cc_chromium.org, stip+watch_chromium.org Visibility:
Public. |
DescriptionRevert of Revert of Make ninja display elapsed compile time by default. (patchset #1 of https://codereview.chromium.org/405733002/)
Reason for revert:
see discussion in https://codereview.chromium.org/268833006/
Original issue's description:
> Revert of Make ninja display elapsed compile time by default. (https://codereview.chromium.org/268833006/)
>
> Reason for revert:
> This made the build pages more noisy and happened to not be as useful as hoped in practice.
>
> If someone wants to use this to debug something, please add it temporarily while you debug, and then remove it again when you're done.
>
> Original issue's description:
> > Make ninja display elapsed compile time by default.
> >
> > This will help debug slow or hanging compiles.
> >
> > BUG=none
> >
> > Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=269042
>
> r287547
TBR=thakis@chromium.org
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=290324
Patch Set 1 #
Created: 6 years, 4 months ago
(Patch set is too large to download)
Messages
Total messages: 30 (0 generated)
Created Revert of Revert of Make ninja display elapsed compile time by default.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/jabdelmalek@google.com/483853002/1
The CQ bit was unchecked by commit-bot@chromium.org
No LGTM from a valid reviewer yet. Only full committers are accepted. Even if an LGTM may have been provided, it was from a non-committer or a provisional committer, _not_ a full super star committer. See http://www.chromium.org/getting-involved/become-a-committer Note that this has nothing to do with OWNERS files.
The CQ bit was checked by jam@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/jabdelmalek@google.com/483853002/1
The CQ bit was unchecked by commit-bot@chromium.org
Failed to apply patch for build/scripts/slave/compile.py:
While running patch -p1 --forward --force --no-backup-if-mismatch;
patching file build/scripts/slave/compile.py
Hunk #1 FAILED at 729.
1 out of 1 hunk FAILED -- saving rejects to file
build/scripts/slave/compile.py.rej
Patch: build/scripts/slave/compile.py
Index: scripts/slave/compile.py
diff --git build/scripts/slave/compile.py build/scripts/slave/compile.py
index
1331afa262fe0049077459578b7d4ad25acf7d37..dc5d3b3e9791692fa6e595c5b957745e4f65c927
100755
--- a/build/scripts/slave/compile.py
+++ b/build/scripts/slave/compile.py
@@ -729,6 +729,7 @@
# Prepare environment.
env = EchoDict(os.environ)
+ env.setdefault('NINJA_STATUS', '[%s/%t | %e] ')
orig_compiler = options.compiler
goma_ready = goma_setup(options, env)
if not goma_ready:
not lgtm (writing up reasoning…)
1. This doesn't help you with compile timings, since the timestamps are from when a job started. You can only use this for durations for things that are serialized (like linking, on some bots) 2. If you have something concrete that you want to investigate, I'm happy with letting this in temporarily while you investigate. But most of the time, noone will look at this.
On 2014/08/18 19:24:35, Nico (very away) wrote: > 1. This doesn't help you with compile timings, since the timestamps are from > when a job started. You can only use this for durations for things that are > serialized (like linking, on some bots) right, right now we have 2 parallel links on bots and before we could see approximately when the links start and stop. now this information is gone. maybe we should be printing more timings to aid in debugging. > > 2. If you have something concrete that you want to investigate, I'm happy with > letting this in temporarily while you investigate. But most of the time, noone > will look at this. i guess i'm not sure how this information is hurting? how is it different from the test timing data we print out in each step?
On Mon, Aug 18, 2014 at 12:29 PM, <jam@chromium.org> wrote: > On 2014/08/18 19:24:35, Nico (very away) wrote: > >> 1. This doesn't help you with compile timings, since the timestamps are >> from >> when a job started. You can only use this for durations for things that >> are >> serialized (like linking, on some bots) >> > > right, right now we have 2 parallel links on bots and before we could see > approximately when the links start and stop. now this information is gone. > > maybe we should be printing more timings to aid in debugging. > > > > 2. If you have something concrete that you want to investigate, I'm happy >> with >> letting this in temporarily while you investigate. But most of the time, >> noone >> will look at this. >> > > i guess i'm not sure how this information is hurting? It adds stuff that most people never look at. I've never seen someone do anything actionable with that data while it was there either, even though people claimed they would use it. > how is it different from > the test timing data we print out in each step? > The test output is horribly noisy, there's lots of unnecessary output in there. Nobody has spent time on cleaning this up. (Also, for tests, the output means something. Here, it's just the timestamp that used to be current when an edge started.) Compile output used to be horribly noisy, but several people put in a lot of work in cleaning it up and making it small and noiseless. > > https://codereview.chromium.org/483853002/ > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
(…and we have much better tooling for folks who want to look into compile perf, e.g. https://github.com/nico/ninjatracing ) On Mon, Aug 18, 2014 at 12:31 PM, Nico Weber <thakis@chromium.org> wrote: > On Mon, Aug 18, 2014 at 12:29 PM, <jam@chromium.org> wrote: > >> On 2014/08/18 19:24:35, Nico (very away) wrote: >> >>> 1. This doesn't help you with compile timings, since the timestamps are >>> from >>> when a job started. You can only use this for durations for things that >>> are >>> serialized (like linking, on some bots) >>> >> >> right, right now we have 2 parallel links on bots and before we could see >> approximately when the links start and stop. now this information is gone. >> >> maybe we should be printing more timings to aid in debugging. >> >> >> >> 2. If you have something concrete that you want to investigate, I'm >>> happy with >>> letting this in temporarily while you investigate. But most of the time, >>> noone >>> will look at this. >>> >> >> i guess i'm not sure how this information is hurting? > > > It adds stuff that most people never look at. I've never seen someone do > anything actionable with that data while it was there either, even though > people claimed they would use it. > > >> how is it different from >> the test timing data we print out in each step? >> > > The test output is horribly noisy, there's lots of unnecessary output in > there. Nobody has spent time on cleaning this up. (Also, for tests, the > output means something. Here, it's just the timestamp that used to be > current when an edge started.) > > Compile output used to be horribly noisy, but several people put in a lot > of work in cleaning it up and making it small and noiseless. > > >> >> https://codereview.chromium.org/483853002/ >> > > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On 2014/08/18 19:31:54, Nico (very away) wrote: > On Mon, Aug 18, 2014 at 12:29 PM, <mailto:jam@chromium.org> wrote: > > > On 2014/08/18 19:24:35, Nico (very away) wrote: > > > >> 1. This doesn't help you with compile timings, since the timestamps are > >> from > >> when a job started. You can only use this for durations for things that > >> are > >> serialized (like linking, on some bots) > >> > > > > right, right now we have 2 parallel links on bots and before we could see > > approximately when the links start and stop. now this information is gone. > > > > maybe we should be printing more timings to aid in debugging. > > > > > > > > 2. If you have something concrete that you want to investigate, I'm happy > >> with > >> letting this in temporarily while you investigate. But most of the time, > >> noone > >> will look at this. > >> > > > > i guess i'm not sure how this information is hurting? > > > It adds stuff that most people never look at. I've never seen someone do > anything actionable with that data while it was there either, even though > people claimed they would use it. > > > > how is it different from > > the test timing data we print out in each step? > > > > The test output is horribly noisy, there's lots of unnecessary output in > there. Nobody has spent time on cleaning this up. (Also, for tests, the > output means something. Here, it's just the timestamp that used to be > current when an edge started.) I'm curious if you would feel different if the timing was step data? Personally I would find it valuable if we could see how much time is spent in links, actions, zipping installer etc... > > Compile output used to be horribly noisy, but several people put in a lot > of work in cleaning it up and making it small and noiseless. Perhaps one core issue here is that on linux/mac this data isn't needed when the compile time is 5-10 minutes on each try run. for windows, this is ~20-60 minutes so we have a massive problem there and no data to figure out where to start. > > > > > > https://codereview.chromium.org/483853002/ > > > > To unsubscribe from this group and stop receiving emails from it, send an email > to mailto:chromium-reviews+unsubscribe@chromium.org.
On Mon, Aug 18, 2014 at 12:34 PM, <jam@chromium.org> wrote: > On 2014/08/18 19:31:54, Nico (very away) wrote: > > On Mon, Aug 18, 2014 at 12:29 PM, <mailto:jam@chromium.org> wrote: >> > > > On 2014/08/18 19:24:35, Nico (very away) wrote: >> > >> >> 1. This doesn't help you with compile timings, since the timestamps are >> >> from >> >> when a job started. You can only use this for durations for things that >> >> are >> >> serialized (like linking, on some bots) >> >> >> > >> > right, right now we have 2 parallel links on bots and before we could >> see >> > approximately when the links start and stop. now this information is >> gone. >> > >> > maybe we should be printing more timings to aid in debugging. >> > >> > >> > >> > 2. If you have something concrete that you want to investigate, I'm >> happy >> >> with >> >> letting this in temporarily while you investigate. But most of the >> time, >> >> noone >> >> will look at this. >> >> >> > >> > i guess i'm not sure how this information is hurting? >> > > > It adds stuff that most people never look at. I've never seen someone do >> anything actionable with that data while it was there either, even though >> people claimed they would use it. >> > > > > how is it different from >> > the test timing data we print out in each step? >> > >> > > The test output is horribly noisy, there's lots of unnecessary output in >> there. Nobody has spent time on cleaning this up. (Also, for tests, the >> output means something. Here, it's just the timestamp that used to be >> current when an edge started.) >> > > I'm curious if you would feel different if the timing was step data? > Personally > I would find it valuable if we could see how much time is spent in links, > actions, zipping installer etc... I wouldn't think putting it in the default bot output where every dev sees it would be useful either. Most people won't look at it. (Like most people don't look at the test timing either.) > Compile output used to be horribly noisy, but several people put in a lot >> of work in cleaning it up and making it small and noiseless. >> > > Perhaps one core issue here is that on linux/mac this data isn't needed > when the > compile time is 5-10 minutes on each try run. for windows, this is ~20-60 > minutes so we have a massive problem there and no data to figure out where > to > start. > Have you tried https://github.com/nico/ninjatracing ? That gives you an about:tracing view that displays which actions run in parallel, etc. (I haven't tried it on Windows, but I'd guess that it'll mostly work.) > > > > > >> > https://codereview.chromium.org/483853002/ >> > >> > > To unsubscribe from this group and stop receiving emails from it, send an >> > email > >> to mailto:chromium-reviews+unsubscribe@chromium.org. >> > > > > https://codereview.chromium.org/483853002/ > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
(having said that, as I said I'm happy with putting this in for a limited time if people want to collect data with it. I just don't think it should be there "just in case", like we don't put LOG() statements in chrome unless things are being actively debugged.) On Mon, Aug 18, 2014 at 12:38 PM, Nico Weber <thakis@chromium.org> wrote: > On Mon, Aug 18, 2014 at 12:34 PM, <jam@chromium.org> wrote: > >> On 2014/08/18 19:31:54, Nico (very away) wrote: >> >> On Mon, Aug 18, 2014 at 12:29 PM, <mailto:jam@chromium.org> wrote: >>> >> >> > On 2014/08/18 19:24:35, Nico (very away) wrote: >>> > >>> >> 1. This doesn't help you with compile timings, since the timestamps >>> are >>> >> from >>> >> when a job started. You can only use this for durations for things >>> that >>> >> are >>> >> serialized (like linking, on some bots) >>> >> >>> > >>> > right, right now we have 2 parallel links on bots and before we could >>> see >>> > approximately when the links start and stop. now this information is >>> gone. >>> > >>> > maybe we should be printing more timings to aid in debugging. >>> > >>> > >>> > >>> > 2. If you have something concrete that you want to investigate, I'm >>> happy >>> >> with >>> >> letting this in temporarily while you investigate. But most of the >>> time, >>> >> noone >>> >> will look at this. >>> >> >>> > >>> > i guess i'm not sure how this information is hurting? >>> >> >> >> It adds stuff that most people never look at. I've never seen someone do >>> anything actionable with that data while it was there either, even though >>> people claimed they would use it. >>> >> >> >> > how is it different from >>> > the test timing data we print out in each step? >>> > >>> >> >> The test output is horribly noisy, there's lots of unnecessary output in >>> there. Nobody has spent time on cleaning this up. (Also, for tests, the >>> output means something. Here, it's just the timestamp that used to be >>> current when an edge started.) >>> >> >> I'm curious if you would feel different if the timing was step data? >> Personally >> I would find it valuable if we could see how much time is spent in links, >> actions, zipping installer etc... > > > I wouldn't think putting it in the default bot output where every dev sees > it would be useful either. Most people won't look at it. (Like most people > don't look at the test timing either.) > > >> Compile output used to be horribly noisy, but several people put in a lot >>> of work in cleaning it up and making it small and noiseless. >>> >> >> Perhaps one core issue here is that on linux/mac this data isn't needed >> when the >> compile time is 5-10 minutes on each try run. for windows, this is ~20-60 >> minutes so we have a massive problem there and no data to figure out >> where to >> start. >> > > Have you tried https://github.com/nico/ninjatracing ? That gives you an > about:tracing view that displays which actions run in parallel, etc. (I > haven't tried it on Windows, but I'd guess that it'll mostly work.) > > >> >> >> >> > >>> > https://codereview.chromium.org/483853002/ >>> > >>> >> >> To unsubscribe from this group and stop receiving emails from it, send an >>> >> email >> >>> to mailto:chromium-reviews+unsubscribe@chromium.org. >>> >> >> >> >> https://codereview.chromium.org/483853002/ >> > > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On 2014/08/18 19:38:03, Nico (very away) wrote: > On Mon, Aug 18, 2014 at 12:34 PM, <mailto:jam@chromium.org> wrote: > > > On 2014/08/18 19:31:54, Nico (very away) wrote: > > > > On Mon, Aug 18, 2014 at 12:29 PM, <mailto:jam@chromium.org> wrote: > >> > > > > > On 2014/08/18 19:24:35, Nico (very away) wrote: > >> > > >> >> 1. This doesn't help you with compile timings, since the timestamps are > >> >> from > >> >> when a job started. You can only use this for durations for things that > >> >> are > >> >> serialized (like linking, on some bots) > >> >> > >> > > >> > right, right now we have 2 parallel links on bots and before we could > >> see > >> > approximately when the links start and stop. now this information is > >> gone. > >> > > >> > maybe we should be printing more timings to aid in debugging. > >> > > >> > > >> > > >> > 2. If you have something concrete that you want to investigate, I'm > >> happy > >> >> with > >> >> letting this in temporarily while you investigate. But most of the > >> time, > >> >> noone > >> >> will look at this. > >> >> > >> > > >> > i guess i'm not sure how this information is hurting? > >> > > > > > > It adds stuff that most people never look at. I've never seen someone do > >> anything actionable with that data while it was there either, even though > >> people claimed they would use it. > >> > > > > > > > how is it different from > >> > the test timing data we print out in each step? > >> > > >> > > > > The test output is horribly noisy, there's lots of unnecessary output in > >> there. Nobody has spent time on cleaning this up. (Also, for tests, the > >> output means something. Here, it's just the timestamp that used to be > >> current when an edge started.) > >> > > > > I'm curious if you would feel different if the timing was step data? > > Personally > > I would find it valuable if we could see how much time is spent in links, > > actions, zipping installer etc... > > > I wouldn't think putting it in the default bot output where every dev sees > it would be useful either. Most people won't look at it. (Like most people > don't look at the test timing either.) > > > > Compile output used to be horribly noisy, but several people put in a lot > >> of work in cleaning it up and making it small and noiseless. > >> > > > > Perhaps one core issue here is that on linux/mac this data isn't needed > > when the > > compile time is 5-10 minutes on each try run. for windows, this is ~20-60 > > minutes so we have a massive problem there and no data to figure out where > > to > > start. > > > > Have you tried https://github.com/nico/ninjatracing ? That gives you an > about:tracing view that displays which actions run in parallel, etc. (I > haven't tried it on Windows, but I'd guess that it'll mostly work.) No I haven't seen that before, thanks I'm trying it out now.
I just noticed that you landed your revert of my revert manually. Can you please undo that? On Mon, Aug 18, 2014 at 1:10 PM, <jam@chromium.org> wrote: > On 2014/08/18 19:38:03, Nico (very away) wrote: > > On Mon, Aug 18, 2014 at 12:34 PM, <mailto:jam@chromium.org> wrote: >> > > > On 2014/08/18 19:31:54, Nico (very away) wrote: >> > >> > On Mon, Aug 18, 2014 at 12:29 PM, <mailto:jam@chromium.org> wrote: >> >> >> > >> > > On 2014/08/18 19:24:35, Nico (very away) wrote: >> >> > >> >> >> 1. This doesn't help you with compile timings, since the timestamps >> are >> >> >> from >> >> >> when a job started. You can only use this for durations for things >> that >> >> >> are >> >> >> serialized (like linking, on some bots) >> >> >> >> >> > >> >> > right, right now we have 2 parallel links on bots and before we could >> >> see >> >> > approximately when the links start and stop. now this information is >> >> gone. >> >> > >> >> > maybe we should be printing more timings to aid in debugging. >> >> > >> >> > >> >> > >> >> > 2. If you have something concrete that you want to investigate, I'm >> >> happy >> >> >> with >> >> >> letting this in temporarily while you investigate. But most of the >> >> time, >> >> >> noone >> >> >> will look at this. >> >> >> >> >> > >> >> > i guess i'm not sure how this information is hurting? >> >> >> > >> > >> > It adds stuff that most people never look at. I've never seen someone >> do >> >> anything actionable with that data while it was there either, even >> though >> >> people claimed they would use it. >> >> >> > >> > >> > > how is it different from >> >> > the test timing data we print out in each step? >> >> > >> >> >> > >> > The test output is horribly noisy, there's lots of unnecessary output >> in >> >> there. Nobody has spent time on cleaning this up. (Also, for tests, the >> >> output means something. Here, it's just the timestamp that used to be >> >> current when an edge started.) >> >> >> > >> > I'm curious if you would feel different if the timing was step data? >> > Personally >> > I would find it valuable if we could see how much time is spent in >> links, >> > actions, zipping installer etc... >> > > > I wouldn't think putting it in the default bot output where every dev sees >> it would be useful either. Most people won't look at it. (Like most people >> don't look at the test timing either.) >> > > > > Compile output used to be horribly noisy, but several people put in a >> lot >> >> of work in cleaning it up and making it small and noiseless. >> >> >> > >> > Perhaps one core issue here is that on linux/mac this data isn't needed >> > when the >> > compile time is 5-10 minutes on each try run. for windows, this is >> ~20-60 >> > minutes so we have a massive problem there and no data to figure out >> where >> > to >> > start. >> > >> > > Have you tried https://github.com/nico/ninjatracing ? That gives you an >> about:tracing view that displays which actions run in parallel, etc. (I >> haven't tried it on Windows, but I'd guess that it'll mostly work.) >> > > No I haven't seen that before, thanks I'm trying it out now. > > https://codereview.chromium.org/483853002/ > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On 2014/08/18 20:17:06, Nico (very away) wrote: > I just noticed that you landed your revert of my revert manually. Can you > please undo that? I had landed that manually since CQ didn't patch it. I'm not sure why you're opposed to printing this extra timing until we at least figure out the windows compile issues.
On Mon, Aug 18, 2014 at 1:59 PM, <jam@chromium.org> wrote: > On 2014/08/18 20:17:06, Nico (very away) wrote: > >> I just noticed that you landed your revert of my revert manually. Can you >> please undo that? >> > > I had landed that manually since CQ didn't patch it. > > I'm not sure why you're opposed to printing this extra timing until we at > least > figure out the windows compile issues. > I'm happy to leave it in for a while if you're actively looking at these numbers. I don't want to leave it in indefinitely, for reasons explained above. > > https://codereview.chromium.org/483853002/ > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On Mon, Aug 18, 2014 at 2:00 PM, Nico Weber <thakis@chromium.org> wrote: > On Mon, Aug 18, 2014 at 1:59 PM, <jam@chromium.org> wrote: > >> On 2014/08/18 20:17:06, Nico (very away) wrote: >> >>> I just noticed that you landed your revert of my revert manually. Can you >>> please undo that? >>> >> >> I had landed that manually since CQ didn't patch it. >> >> I'm not sure why you're opposed to printing this extra timing until we at >> least >> figure out the windows compile issues. >> > > I'm happy to leave it in for a while if you're actively looking at these > numbers. I don't want to leave it in indefinitely, for reasons explained > above. > Is this still needed? To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
yep, still looking at it. likely we'll want it at least until the win32 machines are upgraded On Mon, Aug 25, 2014 at 9:33 AM, Nico Weber <thakis@chromium.org> wrote: > On Mon, Aug 18, 2014 at 2:00 PM, Nico Weber <thakis@chromium.org> wrote: > >> On Mon, Aug 18, 2014 at 1:59 PM, <jam@chromium.org> wrote: >> >>> On 2014/08/18 20:17:06, Nico (very away) wrote: >>> >>>> I just noticed that you landed your revert of my revert manually. Can >>>> you >>>> please undo that? >>>> >>> >>> I had landed that manually since CQ didn't patch it. >>> >>> I'm not sure why you're opposed to printing this extra timing until we >>> at least >>> figure out the windows compile issues. >>> >> >> I'm happy to leave it in for a while if you're actively looking at these >> numbers. I don't want to leave it in indefinitely, for reasons explained >> above. >> > > Is this still needed? > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
Still needed? If so, is it sufficient that http://chromium-build-stats.appspot.com now exposes the same data? On Mon, Aug 25, 2014 at 3:59 PM, John Abd-El-Malek <jabdelmalek@google.com> wrote: > yep, still looking at it. likely we'll want it at least until the win32 > machines are upgraded > > > On Mon, Aug 25, 2014 at 9:33 AM, Nico Weber <thakis@chromium.org> wrote: > >> On Mon, Aug 18, 2014 at 2:00 PM, Nico Weber <thakis@chromium.org> wrote: >> >>> On Mon, Aug 18, 2014 at 1:59 PM, <jam@chromium.org> wrote: >>> >>>> On 2014/08/18 20:17:06, Nico (very away) wrote: >>>> >>>>> I just noticed that you landed your revert of my revert manually. Can >>>>> you >>>>> please undo that? >>>>> >>>> >>>> I had landed that manually since CQ didn't patch it. >>>> >>>> I'm not sure why you're opposed to printing this extra timing until we >>>> at least >>>> figure out the windows compile issues. >>>> >>> >>> I'm happy to leave it in for a while if you're actively looking at these >>> numbers. I don't want to leave it in indefinitely, for reasons explained >>> above. >>> >> >> Is this still needed? >> > > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On Tue, Oct 28, 2014 at 1:33 PM, Nico Weber <thakis@chromium.org> wrote: > Still needed? If so, is it sufficient that > http://chromium-build-stats.appspot.com now exposes the same data? > jam: ping ^^ > > On Mon, Aug 25, 2014 at 3:59 PM, John Abd-El-Malek <jabdelmalek@google.com > > wrote: > >> yep, still looking at it. likely we'll want it at least until the win32 >> machines are upgraded >> >> >> On Mon, Aug 25, 2014 at 9:33 AM, Nico Weber <thakis@chromium.org> wrote: >> >>> On Mon, Aug 18, 2014 at 2:00 PM, Nico Weber <thakis@chromium.org> wrote: >>> >>>> On Mon, Aug 18, 2014 at 1:59 PM, <jam@chromium.org> wrote: >>>> >>>>> On 2014/08/18 20:17:06, Nico (very away) wrote: >>>>> >>>>>> I just noticed that you landed your revert of my revert manually. Can >>>>>> you >>>>>> please undo that? >>>>>> >>>>> >>>>> I had landed that manually since CQ didn't patch it. >>>>> >>>>> I'm not sure why you're opposed to printing this extra timing until we >>>>> at least >>>>> figure out the windows compile issues. >>>>> >>>> >>>> I'm happy to leave it in for a while if you're actively looking at >>>> these numbers. I don't want to leave it in indefinitely, for reasons >>>> explained above. >>>> >>> >>> Is this still needed? >>> >> >> > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On Fri, Oct 31, 2014 at 12:59 PM, Nico Weber <thakis@chromium.org> wrote: > On Tue, Oct 28, 2014 at 1:33 PM, Nico Weber <thakis@chromium.org> wrote: > >> Still needed? If so, is it sufficient that >> http://chromium-build-stats.appspot.com now exposes the same data? >> > > jam: ping ^^ > jam: another ping To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On 2014/11/10 16:33:56, Nico wrote: > jam: another ping I suggest an IM or in-person ping.
On 2014/11/13 13:05:01, Paweł Hajdan Jr. wrote: > On 2014/11/10 16:33:56, Nico wrote: > > jam: another ping > > I suggest an IM or in-person ping. hey, sorry just saw this (for old cls, best to send me private email or IM to bump it up). I don't see the equivalent data in chromium-build-stats? i.e. how is http://chromium-build-stats.appspot.com/compiler_proxy_log/2014/11/14/vm503-m... showing this?
On Fri, Nov 14, 2014 at 8:44 AM, <jam@chromium.org> wrote: > On 2014/11/13 13:05:01, Paweł Hajdan Jr. wrote: > >> On 2014/11/10 16:33:56, Nico wrote: >> > jam: another ping >> > > I suggest an IM or in-person ping. >> > > hey, sorry just saw this (for old cls, best to send me private email or IM > to > bump it up). > > I don't see the equivalent data in chromium-build-stats? i.e. how is > http://chromium-build-stats.appspot.com/compiler_proxy_ > log/2014/11/14/vm503-m4/compiler_proxy.exe.VM503-M4. > chrome-bot.log.INFO.20141114-075320.2924.gz > showing this? > You have to use the ninja_log gs url, not the compiler_proxy_log one: http://chromium-build-stats.appspot.com/ninja_log/2014/11/14/vm682-m1/ninja_l... To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On 2014/11/14 17:05:51, Nico wrote: > On Fri, Nov 14, 2014 at 8:44 AM, <mailto:jam@chromium.org> wrote: > > > On 2014/11/13 13:05:01, Paweł Hajdan Jr. wrote: > > > >> On 2014/11/10 16:33:56, Nico wrote: > >> > jam: another ping > >> > > > > I suggest an IM or in-person ping. > >> > > > > hey, sorry just saw this (for old cls, best to send me private email or IM > > to > > bump it up). > > > > I don't see the equivalent data in chromium-build-stats? i.e. how is > > http://chromium-build-stats.appspot.com/compiler_proxy_ > > log/2014/11/14/vm503-m4/compiler_proxy.exe.VM503-M4. > > chrome-bot.log.INFO.20141114-075320.2924.gz > > showing this? > > > > You have to use the ninja_log gs url, not the compiler_proxy_log one: > http://chromium-build-stats.appspot.com/ninja_log/2014/11/14/vm682-m1/ninja_l... ah, that looks good to me. so we dont need this anymore. > > To unsubscribe from this group and stop receiving emails from it, send an email > to mailto:chromium-reviews+unsubscribe@chromium.org.
Message was sent while issue was closed.
A revert of this CL (patchset #1 id:1) has been created in https://codereview.chromium.org/734143002/ by jam@chromium.org. The reason for reverting is: see discussion in https://codereview.chromium.org/483853002/. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
