FTR, doing optimized builds on the try server is on my plate: http://crbug.com/17946 And arbitrary tests is http://crbug.com/17948
Star them if this is the kind of things that excites you. :) M-A On Thu, Jul 23, 2009 at 7:31 AM, Thomas Van Lenten <thoma...@chromium.org>wrote: > 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 > <scher...@chromium.org>wrote: > >> 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 -~----------~----~----~----~------~----~------~--~---
