Just to be complete, linux can have the same issue, and I'd expect Windows also to be able too. This is one class of things the try server doesn't catch because it is building debug/unoptimized. TVL
On Wed, Jul 22, 2009 at 10:09 PM, Andrew Scherkus <[email protected]>wrote: > On Wed, Jul 22, 2009 at 7:07 PM, Dan Kegel <[email protected]> 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<[email protected]> >> 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 <[email protected]> >> wrote: >> >> >> >> On Wed, Jul 22, 2009 at 5:59 PM, Paweł Hajdan Jr. >> >> <[email protected]> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
