On Wed, Oct 14, 2009 at 9:21 AM, Evan Martin <e...@chromium.org> wrote: > I think the lesson I've learned with this change is that I shouldn't > tackle "hard" bugs to get started in WebKit.
I agree that it's a good idea to start small, the same way the Chromium project asks new contributors to start small. > If I'd had commit access I would've been able to check in/out my patch > immediately when I saw I broke the non-Mac platforms; as it was I > begged someone to cq+ my r+'d patch, came back 20 minutes later to see > that the commit bot flaked, begged someone to set it again, came back > 30 minutes later to learn I'd broken the build, and then had to pawn > off cleaning up the breakage on dglazkov since I couldn't revert it. > :( Normally I would not have cq+'ed your patch and then disappeared. I did that because you seemed enthusiastic about getting your patch landed and, in the worse case, I figured Tony could help dig you out of whatever hole I put you in because his desk is right next to yours. > It seems reasonable enough to me to require me and others start small. There's certainly no requirement to start small. It's more work to interact with the project without the commit bit, but it's certainly possible. > I apologize for my noobness, but I've never been able to understand > the webkit buildbots since a lot of them are red all the time. Is > this documented anywhere? WebKit doesn't have the same "green tree" aesthetic as Chromium does. I think the main reason is because WebKit gets about half as many commits per hour as the main Chromium tree and the commits are more spread out over a 24hr period. Another reason is that the GTK and Qt ports have fewer maintainers than the Mac and Windows ports. If we were to close to tree whenever a bot went red (including the GTK and Qt ports), folks who were less interested in maintaining those ports would end up devoting more time to those ports. However, the project itself doesn't want to play favorites, so we don't want to have an official policy of "close the tree for Mac and Windows redness." Over time, the WebKit tree has been getting greener. When I started working on the project, all the bots were red all the time. The current unofficial culture seems to be as follows: 1) Ensure your change does not introduce new test failures on Mac or Windows by comparing the list of failing tests before and after your change (mentally filtering out the flaky tests). 2) If GTK or QT is compiling before your change, make sure GTK and QT are compiling after your change. 3) If you notice someone disobeying rules (1) or (2), either ping them on IRC or send them email. > One thing that's helped a lot on Chrome is to split the bots into "if > these break, revert your patch" (the builders seen on > http://build.chromium.org/ -- in theory the big box at the top should > be all green), and then "these bots are tracking stuff that we'd like > to keep working" (the builders seen on > http://build.chromium.org/buildbot/waterfall.fyi/console). Or to use > different colors (red = something has gone horribly wrong, orange = > this is broken but maybe ok), for example tracking compile failure vs > layout test fails. The problem with this approach here is that it is counter to the cultural norm of not playing favorites with the ports. Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
