In the wee hours of the morning, I turned on a new bot, which is the first part of the Early Warning System (EWS) that Eric and I have been building. The EWS bots are very much like the style-queue, except they test compilation instead of style.
== Executive Summary == When a patch is posted for review, each EWS bot applies the patch locally and runs build-webkit. If build-webkit succeeds, the bot does nothing. If build-webkit fails, the bot adds a comment to the bug indicating the failure and posts a link to the build log. == Goals == The goal of the EWS is to help us not break the build by providing an early warning for patches that break the build. By posting the build output, the EWS should give contributors some idea how to fix the build even if they can't compile the broken port themselves. If you're especially interested in a particular port, you can subscribe to EWS notifications about that port. When the EWS detects that a patch will break the build for that port, the EWS will automatically CC you on the bug. Currently, I'm the only person subscribed to EWS notifications. If you'd like to subscribe to a particular port, let me know. == Social Contract == Like the style-queue, the EWS is purely advisory. Contributors and reviewers are free to ignore the warnings if they believe the warnings are erroneous or they decide (for whatever reason) to break the build in question. == Frequently Asked Questions == Q) What ports does the EWS support? A) The first EWS bot is for the Chromium port. I have a bot for the Qt port working too, but the build time for the Chromium port was much shorter, so I'm starting with it. My goal is to eventually have a bot for every port (although I haven't worked out the operational issues for non-Linux ports). Q) I wish the EWS supported the foobar port. Can I run an EWS bot myself? A) Yes! The EWS is fully distributed. Anyone can run a EWS bot for whatever platform they're interested in. The bots coordinate via a web service. If you're serious about running an EWS bot for your port, let me know and we can make that happen. Q) Why doesn't the EWS post a success message? I like positive re-enforcement. A) I'm worried about spamming bugs with too many happy status messages. If we have N ports with EWS bots, we don't want to have N happy status messages. Eric and I have some ideas for a more passive success indicator. Once things are running smoothly, we can share some mocks with the list. Q) Why doesn't the bot run the LayoutTests? I'd like to know when I break the LayoutTests on other platforms. A) We'd eventually like to run the LayoutTests, but we're starting with compilation because it's faster and easier. Q) How does the EWS differ from a try server? A) The EWS is similar to a try server farm, but the goal is different. Developers frequently send experimental patches to try servers to see what happens. When you post a patch for review, the expectation is that the patch has some chance of getting r+ed and landed. That means EWS failures should be unusual and worth notifying the subscribers about. Q) How does the EWS deal with patches that don't apply cleanly to TOT? A) The EWS ignores them. It's unclear whether a non-applying patch is good or bad. It might just be dependent on another patch that hasn't been landed yet. Our experience with the style-queue is that most patches apply to TOT when they're posted, so I don't think this is a big limitation. Let me know if you have any questions. You can follow everything the bots do by subscribing to [email protected], but you'll mostly see a bunch of style-queue traffic because the style-queue is much noisier than the EWS. We'll eventually turn <http://webkit-commit-queue.appspot.com/> into an awesome dashboard where you can see all the exciting things the bots are up to. Happy hacking! Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
