On Wed, Jul 22, 2009 at 7:07 PM, Dan Kegel <d...@kegel.com> wrote: > That's consistent with trybots doing debug builds. > Uninitialized var warnings only show up in optimized builds, > nothing we can do there but turn on optimizations.
Gotcha -- thanks for the explanation! Andrew > > > On Thu, Jul 23, 2009 at 2:00 AM, Andrew Scherkus<scher...@chromium.org> > wrote: > > On a related note, Frank (cc'd) ran into an issue where the mac try bots > > have a less-strict compiler warning error than the build bots, which led > to > > a broken build once he checked in: http://codereview.chromium.org/155834 > > Probably a simple config tweak somewhere, but interesting nonetheless. > > Andrew > > On Wed, Jul 22, 2009 at 6:19 PM, Jeremy Orlow <jor...@chromium.org> > wrote: > >> > >> On Wed, Jul 22, 2009 at 5:59 PM, Paweł Hajdan Jr. > >> <phajdan...@chromium.org> wrote: > >>> > >>> One thing that would help us keep the tree more green is avoiding > compile > >>> failures. A compile failure is very bad, because without binaries the > tests > >>> can't run, and then we have to wait for all of them to run, which may > reveal > >>> additional failures etc. > >>> I'm actually surprised by some failures on buildbot, but at least one > >>> thing was not surprising for me: Windows Release compile failures when > the > >>> Debug compiles fine (because we don't have Release trybot). > >> > >> How often does something run in Windows when compiled with the release > >> configuration but not the debug? I've definitely seen it, but I'm not > sure > >> it's terribly common. My guess is that there are other causes of the > build > >> breaking that should be addressed first. Are there any stats on this? > >> My gut feeling is that many of the build breaks are for things that > never > >> passed on a try bot. For example, WebKit gardening patches almost never > >> work on the try bots so we just ignore them. I think working on stuff > like > >> this will bear more fruit. > >> Not to mention that each bot costs a lot in terms of the machine, > >> power, maintenance time, etc. > >> > >>> > >>> What do you think? Do you have any ideas how we could avoid more > compile > >>> failures, even if they are not possible to apply now due to lack of > >>> resources? (for example adding trybots, which seems to not happen > soon). > >>> I was also thinking about allowing simple check-ins when the tree is > >>> "waiting for cycle" state (when the sheriff wants to verify that bots > cycle > >>> green after a lot of redness). The status would say ("Tree closed, > waiting > >>> for cycle; ask sheriff to commit a simple change"), or maybe some > >>> abbreviation for that. It would help people getting code in, and the > sheriff > >>> could require really a lot from that change (like full green trybot > pass > >>> etc). What do you think about that (especially sheriffs)? > >> > >> I think you can always ask the sheriffs if you can put something small > in. > >> I don't see the point of making any such message policy or a > convention. > >> That said, unless it doesn't compile or is REALLY obviously OK, I don't > >> think it's a good idea. > >> > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
